Multimodal sensors enablement in multi-access edge computing (MEC) environments

Abstract

The application relates to multimodal sensors enablement in Multi-access Edge Computing environments. A Multi-access Edge Computing (MEC) host device, including processor circuitry configured to implement at least a part of a MEC system including a MEC platform and one or more MEC application instances, wherein an application entity (AE) of an oneM2M distributed software platform is implemented as a first MEC application instance of the one or more MEC application instances, a multimodal sensor enablement (MUSE) application programming interface (API) is implemented on the MEC platform, and the first MEC application instance is configured to: receive, via the MUSE API, sensor information associated with one or more sensors from a MUSE server; or send, via the MUSE API, a fusion result of the sensor information associated with the one or more sensors to a second MEC application instance of the one or more MEC application instances.

Description

MULTIMODAL SENSORS ENABLEMENT IN MULTI-ACCESS EDGE COMPUTING (MEC) ENVIRONMENTSTECHNICAL FIELD

[0001] Embodiments of the disclosure generally relate to Internet of Things (IoT) and edge computing, and in particular, to multimodal sensors enablement in Multi-access Edge Computing (MEC) environments.BACKGROUND

[0002] Sensor fusion refers to collaboration of two or more sensors to complete object detection and classification tasks. In the field of IoT, the sensor fusion is becoming an increasingly important technology for many application scenarios. Due to that, different sensors have their own advantages and disadvantages, they can complement each other in functions. For example, in the sensor fusion of a radar and a camera, the radar is responsible for estimating a distance, a velocity and an angle of arrival (AoA) of an object, while images captured by the camera are used for object classification based on deep learning. The sensor fusion can provide more comprehensive and superior sensing capabilities than a single sensor, this is very important for enhancing safety and efficiency of intelligent traffic system (ITS) or vehicle-to-everything (V2X) use cases.BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Embodiments of the disclosure will be illustrated, by way of example and not limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements.

[0004] FIG. 1 is a block diagram of a MEC system in accordance with some embodiments of the disclosure.

[0005] FIG. 2 is a block diagram of a MEC host in accordance with some embodiments of  the disclosure.

[0006] FIG. 3 is a diagram of an example resource tree structure of a multimodal sensor enablement (MUSE) application programming interface (API) in accordance with some embodiments of the disclosure.

[0007] FIG. 4 is a sequence diagram of a sensor information acquiring procedure implemented by a MEC application instance as an application function (AF) in accordance with some embodiments of the disclosure.

[0008] FIG. 5 is a sequence diagram of an edge node registration procedure implemented by a MEC application instance as an AF in accordance with some embodiments of the disclosure.

[0009] FIG. 6 is a block diagram of an example machine or device upon which any one or more of the techniques (e.g., procedures) discussed herein may be performed.DETAILED DESCRIPTION

[0010] Various aspects of the illustrative embodiments will be described using terms commonly employed by those skilled in the art to convey the substance of the disclosure to others skilled in the art. However, it will be apparent to those skilled in the art that many alternate embodiments may be practiced using portions of the described aspects. For purposes of explanation, specific numbers, materials, and configurations are set forth in order to provide a thorough understanding of the illustrative embodiments. However, it will be apparent to those skilled in the art that alternate embodiments may be practiced without the specific details. In other instances, well known features may have been omitted or simplified in order to avoid obscuring the illustrative embodiments.

[0011] Further, various operations will be described as multiple discrete operations, in turn, in a manner that is most helpful in understanding the illustrative embodiments; however, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations need not be performed in the order of presentation.

[0012] The phrases “in an embodiment” “in one embodiment” and “in some embodiments” are used repeatedly herein. The phrase generally does not refer to the same embodiment; however, it may. The terms “comprising, ” “having, ” and “including” are synonymous, unless the context dictates otherwise. The phrases “A or B” and “A / B” mean “ (A) , (B) , or (Aand B) . ”

[0013] Considering edge computing real-life scenarios where a number of sensors imposes challenges for interoperability of various applications, it is proposed to expand sensor fusion to various kinds of application scenarios (for example, creating a digital or software-based representation of a real-world environment, such as a road intersection or a factory floor) where information from multiple sensors need to be shared and delivered in edge computing environments.

[0014] European Telecommunications Standards Institute (ETSI) Industry Specification Group (ISG) MEC specifies an architecture for edge computing systems but does not cover so far deployment of nodes and sensors. On the other side, the international standardization body called oneM2M defines an architecture for sensors and nodes, but without integrating that in an edge computing infrastructure.

[0015] In view of the above cases, the disclosure proposes a MEC system in which interoperability of various applications may be ensured by providing a stable and usable mechanism to consume sensor information and data collected from multiple edge nodes.

[0016] FIG. 1 is a block diagram of a MEC system in accordance with some embodiments of the disclosure. As shown in FIG. 1, the MEC system 100 includes a MEC host 102, a MEC system level management unit 104, and a MEC host level management unit 106. The MEC host 102 contains a MEC platform and a virtualization infrastructure. The MEC platform provides MEC services and / or includes a collection of essential functionality required to run MEC applications on the virtualization infrastructure and enable them to provide and / or consume MEC services. The virtualization infrastructure provides compute, storage and network resources for running MEC applications. The MEC system level management unit 104 includes a MEC orchestrator as its core component, which has an overview of a whole of the MEC system 100. The MEC host level management unit 106 includes a MEC platform manager and a virtualization infrastructure manager (VIM) , and handles management of specific functionality of a particular MEC host and MEC applications running on it. It should  be appreciated that the MEC system 100 may include more than one MEC host, and interoperability may be implemented between different MEC application instances within a single MEC host or within different MEC hosts.

[0017] FIG. 2 is a block diagram of the MEC host 102 shown in FIG. 1 in accordance with some embodiments of the disclosure. As shown in FIG. 2, one or more MEC application instances may run on the MEC host 102. An application entity (AE) of an oneM2M distributed software platform may be implemented as a first MEC application instance of the one or more MEC application instances, and a multimodal sensor enablement (MUSE) application programming interface (API) may be implemented on the MEC platform. In this case, the first MEC application instance as the AE may be configured to receive, via the MUSE API, sensor information associated with one or more sensors from a MUSE server; or send, via the MUSE API, a fusion result of the sensor information associated with the one or more sensors to a second MEC application instance of the one or more MEC application instances. That is to say, the MUSE API allows the first MEC application instance to be managed by external systems, and this permits the oneM2M distributed software platform to be plugged into a standard-compliant MEC infrastructure to form the MEC system 100.

[0018] As shown in FIG. 2, in some embodiments, both the AE and a common service entity (CSE) of the oneM2M distributed software platform may be implemented as a single MEC application instance. Alternatively, the CSE of the oneM2M distributed software platform may be implemented as a MEC service offered by the MEC platform or a third MEC application instance of the one or more MEC application instances, wherein the third MEC application instance is a service-producing MEC application instance that produces a service for the first one MEC application instance.

[0019] It should be appreciated that the oneM2M distributed software platform may be implemented on an oneM2M hardware architecture, which includes an application dedicate node (ADN) , an application service node (ASN) , a middle node (MN) , and an infrastructure node (IN) . The ADN includes at least one AE and does not include a CSE. The ASN includes one CSE and at least one AE. The MN includes one CES and may include an AE. The IN includes one CES and may include an AE. An AE may communicate with a CSE no matter the AE and the CSE are implemented on the same hardware node or they are implemented on  different hardware nodes, and CSEs implemented on different hardware nodes may communication with each other. Furthermore, a Non-oneM2M Node (NoDN) , which does not includes an AE nor a CSE, may communicate with the hardware nodes in the oneM2M hardware infrastructure via an interworking proxy entity.

[0020] In some embodiments, each of the one or more MEC application instances may be configured to register its own application information data structure to the MEC platform, and the application information data structure includes an attribute indicating whether the MEC application instance is related to sensor fusion and further includes an attribute describing characteristics of a sensor-enabled edge node which the MEC application instance is tailored to when the MEC application instance is related to sensor fusion. In other words, the first MEC application instance as the AE may be further configured to register its own application information data structure to the MEC platform, and the application information data structure includes an attribute indicating that the first MEC application instance is related to sensor fusion and an attribute describing characteristics of a sensor-enabled edge node which the first MEC application instance is tailored to.

[0021] In some embodiments, time synchronization is an indispensable component in sensor fusion. It makes sure that all involved sensors and other equipment in a sensor fusion solution run on the same clock source. For example, in the V2X / ITS use cases, it is also important to make all involved sensors capture a moving target at the same time, as a time difference between the sensors may result in a target displacement between positions detected by different sensors. Thus, the first MEC application instance as the AE may be further configured to run on the same clock source with the one or more sensors based on a time synchronization method, for example, a global navigation satellite system (GNSS) timing method based on a GNSS satellite clock, a network interface timing method based on an Ethernet interface timing clock, a cellular base station timing method based on a base station air interface timing clock and so on.

[0022] FIG. 3 is a diagram of an example resource tree structure of the MUSE API in accordance with some embodiments of the disclosure. As shown in FIG. 3, in some embodiments, the resource tree structure of the MUSE API may include a sensor information (sensor_info) resource for query (retrieval, update or deletion) of sensor information and an  edge nodes (edge_nodes) resource for registration of sensor-enabled edge nodes.

[0023] FIG. 4 is an example sequence diagram of a sensor information acquiring procedure implemented by the first MEC application instance as the AF in accordance with some embodiments of the disclosure. It should be noted that in FIG. 4 and FIG. 5, various communications of the shown procedures are implemented by Hypertext Transfer Protocol (HTTP) messages; however they may be implemented by other protocols known in the art. As shown in FIG. 4, at S402, the first MEC application instance as the AF sends, via the MUSE API, an HTTP GET request to the MUSE server. The HTTP GET request contains a sensor type associated with the one or more sensors. At S404, the first MEC application instance as the AF receives, via the MUSE API, an HTTP 200 OK response from the MUSE server. The HTTP 200 OK response contains the sensor information associated with the one or more sensors, and the sensor information is determined by the MUSE server based on the sensor type associated with the one or more sensors.

[0024] In some embodiments, the sensor information associated with any one of the one or more sensors contains one or more of a sensor identity, a sensor type, a sensor reading indication, and sensor location information associated with the sensor. Table 1 shows attributes of an example sensor information data structure.

[0025] Table 1

[0026] In some embodiments, the first MEC application instance as the AF may be further  configured to register, via the MUSE API, a sensor-enabled edge node to an edge node resource repository based on ontology model correspondence; send, via the MUSE API, to the MUSE server an HTTP PUT request to update the sensor information associated with a sensor of the sensor-enabled edge node registered in the edge node resource repository; and / or send, via the MUSE API, to the MUSE server an HTTP DELETE request to delete the sensor information associated with a sensor of the sensor-enabled edge node registered in the edge node resource repository.

[0027] FIG. 5 is an example sequence diagram of an edge node registration procedure implemented by the first MEC application instance as the AF in accordance with some embodiments of the disclosure. As shown in FIG. 5, at S502, the first MEC application instance as the AF sends, via the MUSE API, an HTTP POST request to the MUSE server. The POST request contains semantic information associated with the sensor-enabled edge node. At S504, the MUSE server forwards the semantic information associated with the sensor-enabled edge node to an interworking proxy entity and requests for a corresponding ontology instance. At S506, the interworking proxy entity finds an ontology model or template that corresponds to the semantic information associated with the sensor-enabled edge node and creates the ontology instance for the sensor-enabled edge node. At S508, the interworking proxy entity returns the ontology instance for the sensor-enabled edge node to the MUSE server. At S510, the MUSE server creates a resource for the sensor-enabled edge node based on the ontology instance for the sensor-enabled edge node. At S512, the MUSE server sends a HTTP 201 CREATED response to the first MEC application instance as the AF. The HTTP 201 CREATED response contains a representation of the resource created by the MUSE server for the sensor-enabled edge node and a unified resource indicator (URI) of the resource.

[0028] In other words, in the edge node registration procedure, the ontology instance is created by the interworking proxy entity for the sensor-enabled edge node based on the semantic information associated with the sensor-enabled edge node and is requested by the MUSE server from the interworking proxy entity by forwarding the semantic information associated with the sensor-enabled edge node to the interworking proxy entity.

[0029] In some embodiments, the HTTP POST request may contain one or more of a node identity, a node category, a node type, a standardization organization or partnership project  defining an ontology base template for the node category, a semantic description of the ontology instance tailored to the sensor-enabled edge node, a sensor identity, sensor information following the semantic description, connection information of the sensor-enabled edge node, an IP address of the sensor-enabled edge node, and a port number of the sensor-enabled edge node.

[0030] In some embodiments, the HTTP 201 CREATED response may contain one or more of a node identity, a node category, a node type, a reference ontology corresponding to the sensor-enabled edge node, a standardization organization or partnership project defining an ontology base template for the node category, a semantic description of an ontology instance tailored to the sensor-enabled edge node, a sensor identity, sensor information following the semantic description, connection information of the sensor-enabled edge node, an IP address of the sensor-enabled edge node, and a port number of the sensor-enabled edge node.

[0031] In some embodiments, both the HTTP POST request and the HTTP 201 CREATED response may include a node information data structure, and attributes of the node information data structure in the HTTP 201 CREATED response may be permuted, as compared to the ones in the POST request. Table 2 shows attributes of an example node information data structure.

[0032] Table 2

[0033] FIG. 6 is a block diagram of an example machine or device upon which any one or more of the techniques (e.g., procedures) discussed herein may be performed. In other embodiments, the machine 600 may operate as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine 600 may operate in the capacity of a server machine, a client machine, or both in server-client network environments. In an example, the machine 600 may act as a peer machine in peer-to-peer (P2P) (or other distributed) network environments. The machine 600 may be a personal computer (PC) , a tablet PC, a set-top box (STB) , a personal digital assistant (PDA) , a  mobile telephone, a wearable computer device, a web appliance, a network router, a switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine, such as a base station. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the technologies discussed herein, such as cloud computing, software as a service (SaaS) , or other computer cluster configurations.

[0034] Examples, as described herein, may include or may operate on logic or a number of components, modules, or mechanisms. Modules are tangible entities (e.g., hardware) capable of performing specified operations when operating. A module includes hardware. In an example, the hardware may be specifically configured to carry out a specific operation (e.g., hardwired) . In another example, the hardware may include configurable execution units (e.g., transistors, circuits, etc. ) and a computer readable medium containing instructions where the instructions configure the execution units to carry out a specific operation when in operation. The configuring may occur under the direction of the execution units or a loading mechanism. Accordingly, the execution units are communicatively coupled to the computer-readable medium when the device is operating. In this example, the execution units may be a member of more than one module. For example, under operation, the execution units may be configured by a first set of instructions to implement a first module at one point in time and reconfigured by a second set of instructions to implement a second module at a second point in time.

[0035] The machine (e.g., computer system) 600 may include a hardware processor 602 (e.g., a central processing unit (CPU) , a graphics processing unit (GPU) , a hardware processor core, or any combination thereof) , a main memory 604 and a static memory 606, some or all of which may communicate with each other via an interlink (e.g., bus) 608. The machine 600 may further include a power management device 632, a graphics display device 610, an alphanumeric input device 612 (e.g., a keyboard) , and a user interface (UI) navigation device 614 (e.g., a mouse) . In an example, the graphics display device 610, alphanumeric input device 612, and UI navigation device 614 may be a touch screen display. The machine 600 may additionally include a storage device (i.e., drive unit) 616, a signal  generation device 618 (e.g., a speaker) , a MEC device 619, a network interface device / transceiver 620 coupled to antenna (s) 630, and one or more sensors 628, such as a global positioning system (GPS) sensor, a compass, an accelerometer, or other sensor. The machine 600 may include an output controller 634, such as a serial (e.g., universal serial bus (USB) , parallel, or other wired or wireless (e.g., infrared (IR) , near field communication (NFC) , etc. ) connection to communicate with or control one or more peripheral devices (e.g., a printer, a card reader, etc. ) ) . The operations in accordance with one or more example embodiments of the disclosure may be carried out by a baseband processor. The baseband processor may be configured to generate corresponding baseband signals. The baseband processor may further include physical layer (PHY) and medium access control layer (MAC) circuitry, and may further interface with the hardware processor 602 for generation and processing of the baseband signals and for controlling operations of the main memory 604, the storage device 616, and / or the MEC device 619. The baseband processor may be provided on a single radio card, a single chip, or an integrated circuit (IC) .

[0036] The storage device 616 may include a machine readable medium 622 on which is stored one or more sets of data structures or instructions 624 (e.g., software) embodying or utilized by any one or more of the techniques or functions described herein. The instructions 624 may also reside, completely or at least partially, within the main memory 604, within the static memory 606, or within the hardware processor 602 during execution thereof by the machine 600. In an example, one or any combination of the hardware processor 602, the main memory 604, the static memory 606, or the storage device 616 may constitute machine-readable media.

[0037] The MEC device 619 may carry out or perform any of the operations and processes described and shown above.

[0038] It is understood that the above are only a subset of what the MEC device 619 may be configured to perform and that other functions included throughout this disclosure may also be performed by the MEC device 619.

[0039] While the machine-readable medium 622 is illustrated as a single medium, the term "machine-readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) configured to store  the one or more instructions 624.

[0040] Various embodiments may be implemented fully or partially in software and / or firmware. This software and / or firmware may take the form of instructions contained in or on a non-transitory computer-readable storage medium. Those instructions may then be read and executed by one or more processors to enable performance of the operations described herein. The instructions may be in any suitable form, such as but not limited to source code, compiled code, interpreted code, executable code, static code, dynamic code, and the like. Such a computer-readable medium may include any tangible non-transitory medium for storing information in a form readable by one or more computers, such as but not limited to read only memory (ROM) ; random access memory (RAM) ; magnetic disk storage media; optical storage media; a flash memory, etc.

[0041] The term “machine-readable medium” may include any medium that is capable of storing, encoding, or carrying instructions for execution by the machine 600 and that cause the machine 600 to perform any one or more of the techniques of the disclosure, or that is capable of storing, encoding, or carrying data structures used by or associated with such instructions. Non-limiting machine-readable medium examples may include solid-state memories and optical and magnetic media. In an example, a massed machine-readable medium includes a machine-readable medium with a plurality of particles having resting mass. Specific examples of massed machine-readable media may include non-volatile memory, such as semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM) , or electrically erasable programmable read-only memory (EEPROM) ) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

[0042] The instructions 624 may further be transmitted or received over a communications network 626 using a transmission medium via the network interface device / transceiver 620 utilizing any one of a number of transfer protocols (e.g., frame relay, internet protocol (IP) , transmission control protocol (TCP) , user datagram protocol (UDP) , hypertext transfer protocol (HTTP) , etc. ) . Example communications networks may include a local area network (LAN) , a wide area network (WAN) , a packet data network (e.g., the Internet) , mobile telephone networks (e.g., cellular networks) , plain old telephone (POTS) networks, wireless  data networks (e.g., Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards known as  IEEE 802.16 family of standards known as  ) , IEEE 802.15.4 family of standards, and peer-to-peer (P2P) networks, among others. In an example, the network interface device / transceiver 620 may include one or more physical jacks (e.g., Ethernet, coaxial, or phone jacks) or one or more antennas to connect to the communications network 626. In an example, the network interface device / transceiver 620 may include a plurality of antennas to wirelessly communicate using at least one of single-input multiple-output (SIMO) , multiple-input multiple-output (MIMO) , or multiple-input single-output (MISO) techniques. The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding, or carrying instructions for execution by the machine 400 and includes digital or analog communications signals or other intangible media to facilitate communication of such software.

[0043] The operations and processes described and shown above may be carried out or performed in any suitable order as desired in various implementations. Additionally, in certain implementations, at least a portion of the operations may be carried out in parallel. Furthermore, in certain implementations, less than or more than the operations described may be performed.

[0044] The word “exemplary” is used herein to mean “serving as an example, instance, or illustration. ” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments. The MEC host may be implemented by a wireless communication device such as a cellular telephone, a smartphone, a tablet, a netbook, a wireless terminal, a laptop computer, a femtocell, a high data rate (HDR) subscriber station, an access point, a printer, a point of sale device, an access terminal, or other personal communication system (PCS) device. The MEC host may be either mobile or stationary.

[0045] As used herein, unless otherwise specified, the use of the ordinal adjectives “first, ” “second, ” “third, ” etc., to describe a common object, merely indicates that different instances of like objects are being referred to and are not intended to imply that the objects so described must be in a given sequence, either temporally, spatially, in ranking, or in any other manner.

[0046] Some embodiments may be used in conjunction with various devices and systems, for example, a personal computer (PC) , a desktop computer, a mobile computer, a laptop  computer, a notebook computer, a tablet computer, a server computer, a handheld computer, a handheld device, a personal digital assistant (PDA) device, a handheld PDA device, an on-board device, an off-board device, a hybrid device, a vehicular device, a non-vehicular device, a mobile or portable device, a consumer device, a non-mobile or non-portable device, a wireless communication station, a wireless communication device, a wireless access point (AP) , a wired or wireless router, a wired or wireless modem, a video device, an audio device, an audio-video (A / V) device, a wired or wireless network, a wireless area network, a wireless video area network (WVAN) , a local area network (LAN) , a wireless LAN (WLAN) , a personal area network (PAN) , a wireless PAN (WPAN) , and the like.

[0047] Some embodiments may be used in conjunction with one way and / or two-way radio communication systems, cellular radio-telephone communication systems, a mobile phone, a cellular telephone, a wireless telephone, a personal communication system (PCS) device, a PDA device which incorporates a wireless communication device, a mobile or portable global positioning system (GPS) device, a device which incorporates a GPS receiver or transceiver or chip, a device which incorporates an RFID element or chip, a multiple input multiple output (MIMO) transceiver or device, a single input multiple output (SIMO) transceiver or device, a multiple input single output (MISO) transceiver or device, a device having one or more internal antennas and / or external antennas, digital video broadcast (DVB) devices or systems, multi-standard radio devices or systems, a wired or wireless handheld device, e.g., a smartphone, a wireless application protocol (WAP) device, or the like.

[0048] Some embodiments may be used in conjunction with one or more types of wireless communication signals and / or systems following one or more wireless communication protocols, for example, radio frequency (RF) , infrared (IR) , frequency-division multiplexing (FDM) , orthogonal FDM (OFDM) , time-division multiplexing (TDM) , time-division multiple access (TDMA) , extended TDMA (E-TDMA) , general packet radio service (GPRS) , extended GPRS, code-division multiple access (CDMA) , wideband CDMA (WCDMA) , CDMA 2000, single-carrier CDMA, multi-carrier CDMA, multi-carrier modulation (MDM) , discrete multi-tone (DMT) ,  global positioning system (GPS) , Wi-Fi, Wi-Max, ZigBee, ultra-wideband (UWB) , global system for mobile communications (GSM) , 2G, 2.5G, 3G, 3.5G, 4G, 5G, 6G, 3GPP, long term evolution (LTE) , LTE advanced, enhanced data rates for GSM  Evolution (EDGE) , or the like. Other embodiments may be used in various other devices, systems, and / or networks.

[0049] The following paragraphs describe examples of various embodiments.

[0050] Example 1 includes a Multi-access Edge Computing (MEC) host device, comprising processor circuitry configured to implement at least a part of a MEC system including a MEC platform and one or more MEC application instances, wherein an application entity (AE) of an oneM2M distributed software platform is implemented as a first MEC application instance of the one or more MEC application instances, a multimodal sensor enablement (MUSE) application programming interface (API) is implemented on the MEC platform, and the first MEC application instance is configured to: receive, via the MUSE API, sensor information associated with one or more sensors from a MUSE server; or send, via the MUSE API, a fusion result of the sensor information associated with the one or more sensors to a second MEC application instance of the one or more MEC application instances.

[0051] Example 2 includes the MEC host device of Example 1, wherein both the AE and a common service entity (CSE) of the oneM2M distributed software platform are implemented as a single MEC application instance.

[0052] Example 3 includes the MEC host device of Example 1, wherein a common service entity (CSE) of the oneM2M distributed software platform is implemented as a MEC service offered by the MEC platform.

[0053] Example 4 includes the MEC host device of Example 1, wherein a common service entity (CSE) of the oneM2M distributed software platform is implemented as a third MEC application instance of the one or more MEC application instances, and the third MEC application instance is a service-producing MEC application instance that produces a service for the first one MEC application instance.

[0054] Example 5 includes the MEC host device of Example 1, wherein each of the one or more MEC application instances is configured to register its own application information data structure to the MEC platform, and the application information data structure includes an attribute indicating whether the MEC application instance is related to sensor fusion and further includes an attribute describing characteristics of a sensor-enabled edge node which the MEC  application instance is tailored to when the MEC application instance is related to sensor fusion.

[0055] Example 6 includes the MEC host device of Example 1, wherein the first MEC application instance is further configured to run on the same clock source with the one or more sensors based on a time synchronization method.

[0056] Example 7 includes the MEC host device of Example 1, wherein a resource tree structure of the MUSE API includes a sensor information resource for retrieval, update or deletion of sensor information and an edge nodes resource for registration of sensor-enabled edge nodes.

[0057] Example 8 includes the MEC host device of Example 1, wherein the sensor information associated with any one of the one or more sensors contains one or more of a sensor identity, a sensor type, a sensor reading indication, and sensor location information of associated with the sensor.

[0058] Example 9 includes the MEC host device of Example 1, wherein the first MEC application instance is further configured to: send, via the MUSE API, a GET request to the MUSE server, wherein the GET request contains a sensor type associated with the one or more sensors; and receive, via the MUSE API, a 200 OK response from the MUSE server, wherein the 200 OK response contains the sensor information associated with the one or more sensors, which is determined by the MUSE server based on the sensor type associated with the one or more sensors.

[0059] Example 10 includes the MEC host device of Example 1, wherein the first MEC application instance is further configured to register, via the MUSE API, a sensor-enabled edge node to an edge node resource repository based on ontology model correspondence.

[0060] Example 11 includes the MEC host device of Example 10, wherein the first MEC application instance is further configured to send, via the MUSE API, to the MUSE server a PUT request to update the sensor information associated with a sensor of the sensor-enabled edge node.

[0061] Example 12 includes the MEC host device of Example 10, wherein the first MEC application instance is further configured to send, via the MUSE API, to the MUSE server a  DELETE request to delete the sensor information associated with a sensor of the sensor-enabled edge node.

[0062] Example 13 includes the MEC host device of Example 10, wherein the first MEC application instance is further configured to: send, via the MUSE API, a POST request to the MUSE server, wherein the POST request contains semantic information associated with the sensor-enabled edge node; and receive, via the MUSE API, a 201 CREATED response from the MUSE server, wherein the 201 CREATED response contains a representation of a resource created by the MUSE server for the sensor-enabled edge node based on an ontology instance and a unified resource indicator (URI) of the resource, and the ontology instance is created by an interworking proxy entity for the sensor-enabled edge node based on the semantic information and is requested by the MUSE server from the interworking proxy entity by forwarding the semantic information to the interworking proxy entity.

[0063] Example 14 includes the MEC host device of Example 13, wherein the POST request contains one or more of a node identity, a node category, a node type, a standardization organization or partnership project defining an ontology base template for the node category, a semantic description of the ontology instance tailored to the sensor-enabled edge node, a sensor identity, sensor information following the semantic description, connection information of the sensor-enabled edge node, an IP address of the sensor-enabled edge node, and a port number of the sensor-enabled edge node.

[0064] Example 15 includes the MEC host device of Example 13, wherein the 201 CREATED response contains one or more of a node identity, a node category, a node type, a reference ontology corresponding to the sensor-enabled edge node, a standardization organization or partnership project defining an ontology base template for the node category, a semantic description of an ontology instance tailored to the sensor-enabled edge node, a sensor identity, sensor information following the semantic description, connection information of the sensor-enabled edge node, an IP address of the sensor-enabled edge node, and a port number of the sensor-enabled edge node.

[0065] Example 16 includes a non-transitory computer readable storage medium storing computer executable instructions thereon, wherein the computer executable instructions, when executed by a processor, cause the processor to implement at least a part of a MEC system  including a MEC platform and one or more MEC application instances, wherein an Application Entity (AE) of an oneM2M distributed software platform is implemented as a first MEC application instance of the one or more MEC application instances, a multimodal sensor enablement (MUSE) application programming interface (API) is implemented on the MEC platform, and the first MEC application instance is configured to: receive, via the MUSE API, sensor information associated with one or more sensors from a MUSE server; or send, via the MUSE API, a fusion result of the sensor information associated with the one or more sensors to a second MEC application instance of the one or more MEC application instances.

[0066] Example 17 includes the non-transitory computer readable storage medium of Example 16, wherein both the AE and a common service entity (CSE) of the oneM2M distributed software platform are implemented as a single MEC application instance.

[0067] Example 18 includes the non-transitory computer readable storage medium of Example 16, wherein a common service entity (CSE) of the oneM2M distributed software platform is implemented as a MEC service offered by the MEC platform.

[0068] Example 19 includes the non-transitory computer readable storage medium of Example 16, wherein a common service entity (CSE) of the oneM2M distributed software platform is implemented as a third MEC application instance of the one or more MEC application instances, and the third MEC application instance is a service-producing MEC application instance that produces a service for the first one MEC application instance.

[0069] Example 20 includes the non-transitory computer readable storage medium of Example 16, wherein each of the one or more MEC application instances is configured to register its own application information data structure to the MEC platform, and the application information data structure includes an attribute indicating whether the MEC application instance is related to sensor fusion and further includes an attribute describing characteristics of a sensor-enabled edge node which the MEC application instance is tailored to when the MEC application instance is related to sensor fusion.

[0070] Example 21 includes the non-transitory computer readable storage medium of Example 16, wherein the first MEC application instance is further configured to run on the same clock source with the one or more sensors based on a time synchronization method.

[0071] Example 22 includes the non-transitory computer readable storage medium of Example 16, wherein a resource tree structure of the MUSE API includes a sensor information resource for retrieval, update or deletion of sensor information and an edge nodes resource for registration of sensor-enabled edge nodes.

[0072] Example 23 includes the non-transitory computer readable storage medium of Example 16, wherein the sensor information associated with any one of the one or more sensors contains one or more of a sensor identity, a sensor type, a sensor reading indication, and sensor location information of associated with the sensor.

[0073] Example 24 includes the non-transitory computer readable storage medium of Example 16, wherein the first MEC application instance is further configured to: send, via the MUSE API, a GET request to the MUSE server, wherein the GET request contains a sensor type associated with the one or more sensors; and receive, via the MUSE API, a 200 OK response from the MUSE server, wherein the 200 OK response contains the sensor information associated with the one or more sensors, which is determined by the MUSE server based on the sensor type associated with the one or more sensors.

[0074] Example 25 includes the non-transitory computer readable storage medium of Example 16, wherein the first MEC application instance is further configured to register, via the MUSE API, a sensor-enabled edge node to an edge node resource repository based on ontology model correspondence.

[0075] Example 26 includes the non-transitory computer readable storage medium of Example 25, wherein the first MEC application instance is further configured to send, via the MUSE API, to the MUSE server a PUT request to update the sensor information associated with a sensor of the sensor-enabled edge node.

[0076] Example 27 includes the non-transitory computer readable storage medium of Example 25, wherein the first MEC application instance is further configured to send, via the MUSE API, to the MUSE server a DELETE request to delete the sensor information associated with a sensor of the sensor-enabled edge node.

[0077] Example 28 includes the non-transitory computer readable storage medium of Example 25, wherein the first MEC application instance is further configured to: send, via the  MUSE API, a POST request to the MUSE server, wherein the POST request contains semantic information associated with the sensor-enabled edge node; and receive, via the MUSE API, a 201 CREATED response from the MUSE server, wherein the 201 CREATED response contains a representation of a resource created by the MUSE server for the sensor-enabled edge node based on an ontology instance and a unified resource indicator (URI) of the resource, and the ontology instance is created by an interworking proxy entity for the sensor-enabled edge node based on the semantic information and is requested by the MUSE server from the interworking proxy entity by forwarding the semantic information to the interworking proxy entity.

[0078] Example 29 includes the non-transitory computer readable storage medium of Example 28, wherein the POST request contains one or more of a node identity, a node category, a node type, a standardization organization or partnership project defining an ontology base template for the node category, a semantic description of the ontology instance tailored to the sensor-enabled edge node, a sensor identity, sensor information following the semantic description, connection information of the sensor-enabled edge node, an IP address of the sensor-enabled edge node, and a port number of the sensor-enabled edge node.

[0079] Example 30 includes the non-transitory computer readable storage medium of Example 28, wherein the 201 CREATED response contains one or more of a node identity, a node category, a node type, a reference ontology corresponding to the sensor-enabled edge node, a standardization organization or partnership project defining an ontology base template for the node category, a semantic description of an ontology instance tailored to the sensor-enabled edge node, a sensor identity, sensor information following the semantic description, connection information of the sensor-enabled edge node, an IP address of the sensor-enabled edge node, and a port number of the sensor-enabled edge node.

[0080] Example 31 includes a computer program product comprising computer executable instructions, wherein the computer executable instructions, when executed by a processor, cause the processor to implement at least a part of a MEC system including a MEC platform and one or more MEC application instances, wherein an application entity (AE) of an oneM2M distributed software platform is implemented as a first MEC application instance of the one or more MEC application instances, a multimodal sensor enablement (MUSE) application  programming interface (API) is implemented on the MEC platform, and the first MEC application instance is configured to: receive, via the MUSE API, sensor information associated with one or more sensors from a MUSE server; or send, via the MUSE API, a fusion result of the sensor information associated with the one or more sensors to a second MEC application instance of the one or more MEC application instances.

[0081] Example 32 includes the computer program product of Example 31, wherein both the AE and a common service entity (CSE) of the oneM2M distributed software platform are implemented as a single MEC application instance.

[0082] Example 33 includes the computer program product of Example 31, wherein a common service entity (CSE) of the oneM2M distributed software platform is implemented as a MEC service offered by the MEC platform.

[0083] Example 34 includes the computer program product of Example 31, wherein a common service entity (CSE) of the oneM2M distributed software platform is implemented as a third MEC application instance of the one or more MEC application instances, and the third MEC application instance is a service-producing MEC application instance that produces a service for the first one MEC application instance.

[0084] Example 35 includes the computer program product of Example 31, wherein each of the one or more MEC application instances is configured to register its own application information data structure to the MEC platform, and the application information data structure includes an attribute indicating whether the MEC application instance is related to sensor fusion and further includes an attribute describing characteristics of a sensor-enabled edge node which the MEC application instance is tailored to when the MEC application instance is related to sensor fusion.

[0085] Example 36 includes the computer program product of Example 31, wherein the first MEC application instance is further configured to run on the same clock source with the one or more sensors based on a time synchronization method.

[0086] Example 37 includes the computer program product of Example 31, wherein a resource tree structure of the MUSE API includes a sensor information resource for retrieval, update or deletion of sensor information and an edge nodes resource for registration of sensor- enabled edge nodes.

[0087] Example 38 includes the computer program product of Example 31, wherein the sensor information associated with any one of the one or more sensors contains one or more of a sensor identity, a sensor type, a sensor reading indication, and sensor location information of associated with the sensor.

[0088] Example 39 includes the computer program product of Example 31, wherein the first MEC application instance is further configured to: send, via the MUSE API, a GET request to the MUSE server, wherein the GET request contains a sensor type associated with the one or more sensors; and receive, via the MUSE API, a 200 OK response from the MUSE server, wherein the 200 OK response contains the sensor information associated with the one or more sensors, which is determined by the MUSE server based on the sensor type associated with the one or more sensors.

[0089] Example 40 includes the computer program product of Example 31, wherein the first MEC application instance is further configured to register, via the MUSE API, a sensor-enabled edge node to an edge node resource repository based on ontology model correspondence.

[0090] Example 41 includes the computer program product of Example 40, wherein the first MEC application instance is further configured to send, via the MUSE API, to the MUSE server a PUT request to update the sensor information associated with a sensor of the sensor-enabled edge node.

[0091] Example 42 includes the computer program product of Example 40, wherein the first MEC application instance is further configured to send, via the MUSE API, to the MUSE server a DELETE request to delete the sensor information associated with a sensor of the sensor-enabled edge node.

[0092] Example 43 includes the computer program product of Example 40, wherein the first MEC application instance is further configured to: send, via the MUSE API, a POST request to the MUSE server, wherein the POST request contains semantic information associated with the sensor-enabled edge node; and receive, via the MUSE API, a 201 Created response from the MUSE server, wherein the 201 CREATED response contains a  representation of a resource created by the MUSE server for the sensor-enabled edge node based on an ontology instance and a unified resource indicator (URI) of the resource, and the ontology instance is created by an interworking proxy entity for the sensor-enabled edge node based on the semantic information and is requested by the MUSE server from the interworking proxy entity by forwarding the semantic information to the interworking proxy entity.

[0093] Example 44 includes the computer program product of Example 43, wherein the POST request contains one or more of a node identity, a node category, a node type, a standardization organization or partnership project defining an ontology base template for the node category, a semantic description of the ontology instance tailored to the sensor-enabled edge node, a sensor identity, sensor information following the semantic description, connection information of the sensor-enabled edge node, an IP address of the sensor-enabled edge node, and a port number of the sensor-enabled edge node.

[0094] Example 45 includes the computer program product of Example 43, wherein the 201 CREATED response contains one or more of a node identity, a node category, a node type, a reference ontology corresponding to the sensor-enabled edge node, a standardization organization or partnership project defining an ontology base template for the node category, a semantic description of an ontology instance tailored to the sensor-enabled edge node, a sensor identity, sensor information following the semantic description, connection information of the sensor-enabled edge node, an IP address of the sensor-enabled edge node, and a port number of the sensor-enabled edge node.

[0095] Although certain embodiments have been illustrated and described herein for purposes of description, a wide variety of alternate and / or equivalent embodiments or implementations calculated to achieve the same purposes may be substituted for the embodiments shown and described without departing from the scope of the disclosure. This application is intended to cover any adaptations or variations of the embodiments discussed herein. Therefore, it is manifestly intended that embodiments described herein be limited only by the appended claims and the equivalents thereof.

Claims

1.A Multi-access Edge Computing (MEC) host device, comprising processor circuitry to configure a first MEC application instance to:receive, via a multimodal sensor enablement (MUSE) application programming interface (API) , sensor information associated with one or more sensors from a MUSE server; orsend, via the MUSE API, a fusion result of the sensor information associated with the one or more sensors to a second MEC application instance.2.The MEC host device of claim 1, wherein the processor circuitry is further to configure the first MEC application instance as both an application entity (AE) and a common service entity (CSE) of an oneM2M distributed software platform.3.The MEC host device of claim 1, wherein the processor circuitry is further to configure the first MEC application instance as an application entity (AE) of an oneM2M distributed software platform.4.The MEC host device of claim 1, wherein a common service entity (CSE) of an oneM2M distributed software platform is implemented as a third MEC application instance, and the third MEC application instance is a service-producing MEC application instance that produces a service for the first MEC application instance.5.The MEC host device of claim 1, wherein the processor circuitry is further to configure the first MEC application instance to register its own application information data structure to a MEC platform, and the application information data structure includes an attribute indicating whether the first MEC application instance is related to sensor fusion and further includes an attribute describing characteristics of a sensor-enabled edge node which the first MEC application instance is tailored to when the first MEC application instance is related to sensor fusion.6.The MEC host device of claim 1, wherein the processor circuitry is further to configure the first MEC application instance to run on the same clock source with the one or more sensors based on a time synchronization method.7.The MEC host device of claim 1, wherein a resource tree structure of the MUSE API includes a sensor information resource for retrieval, update or deletion of sensor information and an edge nodes resource for registration of sensor-enabled edge nodes.8.The MEC host device of claim 1, wherein the sensor information associated with any one of the one or more sensors contains one or more of a sensor identity, a sensor type, a sensor reading indication, and sensor location information associated with the sensor.9.The MEC host device of claim 1, wherein the processor circuitry is further to configure the first MEC application instance to:send, via the MUSE API, a GET request to the MUSE server, wherein the GET request contains a sensor type associated with the one or more sensors; andreceive, via the MUSE API, a 200 OK response from the MUSE server, wherein the 200 OK response contains the sensor information associated with the one or more sensors, which is determined by the MUSE server based on the sensor type associated with the one or more sensors.10.The MEC host device of claim 1, wherein the processor circuitry is further to configure the first MEC application instance to register, via the MUSE API, a sensor-enabled edge node to an edge node resource repository based on ontology model correspondence.11.The MEC host device of claim 10, wherein the processor circuitry is further to configure the first MEC application instance to send, via the MUSE API, to the MUSE server a PUT request to update the sensor information associated with a sensor of the sensor-enabled edge node.12.The MEC host device of claim 10, wherein the processor circuitry is further to configure the first MEC application instance to send, via the MUSE API, to the MUSE server a DELETE request to delete the sensor information associated with a sensor of the sensor-enabled edge node.13.A non-transitory computer readable storage medium storing computer executable instructions thereon, wherein the computer executable instructions, when executed by a processor, cause the processor to configure a first Multi-access Edge Computing (MEC) application instance to:receive, via a multimodal sensor enablement (MUSE) application programming interface (API) , sensor information associated with one or more sensors from a MUSE server; orsend, via the MUSE API, a fusion result of the sensor information associated with the one or more sensors to a second MEC application instance.14.The non-transitory computer readable storage medium of claim 13, wherein the computer executable instructions, when executed by the processor, further cause the processor to configure the first MEC application instance as both an application entity (AE) and a common service entity (CSE) of an oneM2M distributed software platform.15.The non-transitory computer readable storage medium of claim 13, wherein the computer executable instructions, when executed by the processor, further cause the processor to configure the first MEC application instance as an application entity (AE) of an oneM2M distributed software platform.16.The non-transitory computer readable storage medium of claim 13, wherein a common service entity (CSE) of an oneM2M distributed software platform is implemented as a third MEC application instance, and the third MEC application instance is a service-producing MEC application instance that produces a service for the first MEC application instance.17.The non-transitory computer readable storage medium of claim 13, wherein the computer executable instructions, when executed by the processor, further cause the processor to configure the first MEC application instance to register its own application information data structure to a MEC platform, and the application information data structure includes an attribute indicating whether the first MEC application instance is related to sensor fusion and further includes an attribute describing characteristics of a sensor-enabled edge node which the first MEC application instance is tailored to when the first MEC application instance is related to sensor fusion.18.The non-transitory computer readable storage medium of claim 13, wherein the computer executable instructions, when executed by the processor, further cause the processor to configure the first MEC application instance to run on the same clock source with the one or more sensors based on a time synchronization method.19.The non-transitory computer readable storage medium of claim 13, wherein a resource tree structure of the MUSE API includes a sensor information resource for retrieval, update or deletion of sensor information and an edge nodes resource for registration of sensor-enabled edge nodes.20.The non-transitory computer readable storage medium of claim 13, wherein the sensor information associated with any one of the one or more sensors contains one or more of a sensor identity, a sensor type, a sensor reading indication, and sensor location information associated with the sensor.

Images