Method, device and storage medium for processing media content in MPEG NBMP

Abstract

Provided are a method, apparatus, and storage medium for processing media content in MPEG NBMP. The method includes receiving, by a first application running on an application server, a real-time session request from a second application running on a user device separate from the application server to initiate an uplink live streaming framework (FLUS) session; obtaining a list of multiple FLUS receivers; selecting a FLUS media receiver running on a receiver device separate from the application server and the user device from the multiple FLUS receivers; sending a workflow request to a network-based media processing (NBMP) source to initiate an NBMP workflow associated with the FLUS media receiver; and sending a response to the second application using the NBMP workflow and the FLUS media receiver, the response including session information for establishing the FLUS session.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Application No. 63 / 050,517 filed on July 10, 2020, U.S. Provisional Application No. 63 / 066,703 filed on August 17, 2020, and U.S. Patent Application No. 17 / 337,964 filed on June 3, 2021, the disclosures of which are hereby incorporated by reference in their entirety. Technical Field

[0003] The embodiments of the present disclosure relate to methods and systems for media processing and streaming, and more particularly to methods, devices, and storage media for processing media content in Moving Picture Experts Group (MPEG) Network-Based Media Processing (NBMP). Background Art

[0004] The Moving Picture Experts Group (MPEG) Network-Based Media Processing (NBMP) project developed concepts for processing media in the cloud. The entire contents of "ISO / IEC DIS 23090-8 Text for Network-Based Media Processing" ISO / IEC JTC 1 / SC 29 / WG 11 (N 18657), dated July 12, 2019, are incorporated herein by reference.

[0005] The 3rd Generation Partnership Project (3GPP) FLUS protocol provides a mechanism for uplink streaming of multimedia content from a source device to a network and for sending / distributing the content to one or more destinations. The entire contents of 3GPP TS 26.238 V16.2.0, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Uplink Flow (Release 16)" dated September 2019, are incorporated herein by reference.

[0006] The 3GPP edge protocol defines a general architecture for supporting edge applications, including discovering the hardware capabilities of edge elements. The entire content of 3GPP TS 23.558 V0.3.0, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture to Support Edge Applications (Release 17)" June 2020, is incorporated herein by reference. Summary of the Invention

[0007] According to one or more embodiments, a method for processing media content in MPEG NBMP is provided. The method includes: a first application running on an application server receives a real-time session request from a second application running on a user device separate from the application server to initiate a FLUS session; obtaining a list of multiple FLUS receivers; selecting a FLUS media receiver running on a receiver device separate from the application server and the user device from the multiple FLUS receivers; sending a workflow request to an NBMP source to initiate an NBMP workflow associated with the FLUS media receiver; and sending a response to the second application using the NBMP workflow and the FLUS media receiver, the response including session information for establishing the FLUS session.

[0008] According to one or more embodiments, an apparatus for processing media content in MPEG NBMP is provided. The apparatus includes: at least one memory configured to store program code; and at least one processor configured to read the program code and execute according to instructions of the program code, wherein the program code includes: a receiving code configured to cause the at least one processor to receive a real-time session request from a second application running on a user device separate from the application server through a first application running on an application server to initiate an uplink real-time streaming framework (FLUS) session; an acquiring code configured to cause the at least one processor to obtain a list of multiple FLUS receivers; a selecting code configured to cause the at least one processor to select a FLUS media receiver running on a receiving device from the multiple FLUS receivers, the receiving device being separate from the application server and the user device; a first sending code configured to cause the at least one processor to send a workflow request to an NBMP source to initiate an NBMP workflow associated with the FLUS media receiver; and a second sending code configured to cause the at least one processor to send a response to the second application using the NBMP workflow and the FLUS media receiver, the response including session information for establishing a FLUS session.

[0009] According to one or more embodiments, a non-transitory computer-readable storage medium storing computer instructions is provided. The computer instructions are configured to, when executed by at least one processor in an apparatus for processing media content in MPEG NBMP, cause the at least one processor to: receive, by a first application running on an application server, a real-time session request from a second application running on a user device separate from the application server to initiate an uplink real-time streaming framework (FLUS) session; obtain a list of multiple FLUS receivers; select a FLUS media receiver running on a receiver device separate from the application server and the user device from the multiple FLUS receivers; send a workflow request to an NBMP source to initiate an NBMP workflow associated with the FLUS media receiver; and send a response to the second application using the NBMP workflow and the FLUS media receiver, the response including session information for establishing the FLUS session. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Further features, properties, and various advantages of the disclosed subject matter will become more apparent from the following detailed description and accompanying drawings, in which:

[0011] Figure 1 is a schematic diagram of an environment according to an embodiment in which the methods, apparatuses, and systems described herein may be implemented.

[0012] Figure 2 yes Figure 1 A block diagram of example components of one or more devices.

[0013] Figure 3 is a block diagram of an NBMP system according to an embodiment.

[0014] Figure 4 is a block diagram of a 3GPP FLUS architecture according to an embodiment.

[0015] Figure 5 is a block diagram of a network architecture according to an embodiment.

[0016] Figure 6 is a block diagram of a network architecture according to an embodiment.

[0017] Figure 7 is a block diagram of a network architecture according to an embodiment.

[0018] Figure 8 is a block diagram of a network architecture according to an embodiment.

[0019] Figure 9 is a block diagram of a network architecture according to an embodiment.

[0020] Figure 10is a block diagram of a network architecture according to an embodiment.

[0021] Figure 11 is a block diagram of a network architecture according to an embodiment.

[0022] Figure 12 is a block diagram of a network architecture according to an embodiment.

[0023] Figure 13 is a block diagram illustrating an example process for network capability discovery, according to an embodiment.

[0024] Figure 14 is a block diagram of a network architecture according to an embodiment.

[0025] Figure 15 is a flow diagram of an example process for managing capabilities of a streaming media network, according to an embodiment. DETAILED DESCRIPTION

[0026] Figure 1 is a diagram of an environment 100 in which the methods, apparatuses, and systems described herein may be implemented, according to an embodiment. Figure 1 As shown, environment 100 may include user device 110, platform 120, and network 130. The devices of environment 100 may be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections.

[0027] User device 110 includes one or more devices that can receive, generate, store, process, and / or provide information associated with platform 120. For example, user device 110 may include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a smart speaker, a server, etc.), a mobile phone (e.g., a smartphone, a wireless phone, etc.), a wearable device (e.g., smart glasses or a smart watch), or the like. In some embodiments, user device 110 can receive information from platform 120 and / or send information to platform 120.

[0028] The platform 120 includes one or more devices as described elsewhere in this disclosure. In some embodiments, the platform 120 may include a cloud server or a group of cloud servers. In some embodiments, the platform 120 may be designed to be modular so that software components can be swapped in and out based on specific needs. Thus, the platform 120 can be easily and / or quickly reconfigured for different uses.

[0029] In some embodiments, as shown, the platform 120 can be hosted in a cloud computing environment 122. It is worth noting that while the embodiments described herein describe the platform 120 as being hosted in a cloud computing environment 122, in some embodiments, the platform 120 may not be cloud-based (i.e., may be implemented outside of a cloud computing environment) or may be partially cloud-based.

[0030] Cloud computing environment 122 includes an environment hosting platform 120. Cloud computing environment 122 can provide computing, software, data access, storage, and other services without requiring end users (e.g., user devices 110) to be aware of the physical location and configuration of the systems and / or devices hosting platform 120. As shown, cloud computing environment 122 can include a set of computing resources 124 (collectively, "computing resources 124" and individually, "computing resource 124").

[0031] Computing resources 124 include one or more personal computers, workstation computers, server devices, or other types of computing and / or communication devices. In some embodiments, computing resources 124 can host platform 120. Cloud resources can include computing instances executed in computing resources 124, storage devices provided in computing resources 124, data transmission devices provided by computing resources 124, etc. In some embodiments, computing resources 124 can communicate with other computing resources 124 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0032] like Figure 1 As further shown, the computing resources 124 include a set of cloud resources, such as one or more applications ("APPs") 124-1, one or more virtual machines ("VMs") 124-2, virtualized storage ("VSs") 124-3, or one or more hypervisors ("HYPs") 124-4.

[0033] Applications 124-1 include one or more software applications that can be provided to or accessed by user device 110 and / or platform 120. Applications 124-1 do not require software applications to be installed and executed on user device 110. For example, applications 124-1 may include software associated with platform 120 and / or any other software that can be provided through cloud computing environment 122. In some embodiments, one application 124-1 can send / receive information to or from one or more other applications 124-1 via virtual machine 124-2.

[0034] The virtual machine 124-2 comprises a software implementation of a machine (e.g., a computer) that executes programs, similar to a physical machine. The virtual machine 124-2 can be a system virtual machine or a process virtual machine, depending on the use and correspondence of the virtual machine 124-2 to any real machine. A system virtual machine can provide a complete system platform that supports the execution of a complete operating system ("OS"). A process virtual machine can execute a single program and can support a single process. In some embodiments, the virtual machine 124-2 can execute on behalf of a user (e.g., user device 110) and can manage the infrastructure of the cloud computing environment 122, such as data management, synchronization, or long-term data transfer.

[0035] Virtualized storage 124-3 includes one or more storage systems and / or one or more devices that use virtualization technology within the storage system or device of the computing resource 124. In some embodiments, within the context of the storage system, the types of virtualization may include block virtualization and file virtualization. Block virtualization may refer to the abstraction (or separation) of logical storage from physical storage so that the storage system can be accessed without regard to physical storage or heterogeneous structures. Separation may allow administrators of the storage system to flexibly manage storage for end users. File virtualization may eliminate the dependency between data accessed at the file level and the location of the physical storage file. This may optimize storage usage, server consolidation, and / or the ability to migrate files without disruption.

[0036] Hypervisor 124-4 can provide hardware virtualization technology that allows multiple operating systems (e.g., "guest operating systems") to execute simultaneously on a host computer such as computing resource 124. Hypervisor 124-4 can provide a virtual operating platform to the guest operating systems and can manage the execution of the guest operating systems. Multiple instances of various operating systems can share virtualized hardware resources.

[0037] The network 130 includes one or more wired and / or wireless networks. For example, the network 130 may include a cellular network (e.g., a fifth generation (5G) network, a Long-Term Evolution (LTE) network, a third generation (3G) network, a Code Division Multiple Access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., a public switched telephone network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber-optic-based network, etc., and / or a combination of these or other types of networks.

[0038] supply Figure 1 The number and arrangement of devices and networks shown are examples. Figure 1 There may be more devices and / or networks, fewer devices and / or networks, different devices and / or networks, or differently arranged devices and / or networks than those shown. Figure 1 Two or more of the devices shown may be implemented in a single device, or Figure 1 The single device shown may be implemented as multiple distributed devices. Additionally or alternatively, one set of devices (eg, one or more devices) of environment 100 may perform one or more functions described as being performed by another set of devices of environment 100.

[0039] Figure 2 yes Figure 1 The electronic device 200 may correspond to the user device 110 and / or the platform 120. Figure 2 As shown, the electronic device 200 may include a bus 210 , a processor 220 , a memory 230 , a storage component 240 , an input component 250 , an output component 260 , and a communication interface 270 .

[0040] The bus 210 includes components that allow communication between components of the electronic device 200. The processor 220 is implemented in hardware, firmware, or a combination of hardware and software. The processor 220 is a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or another type of processing component. In some embodiments, the processor 220 includes one or more processors that can be programmed to perform functions. The memory 230 includes a random access memory (RAM), a read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) that stores information and / or instructions for use by the processor 220.

[0041] The storage component 240 stores information and / or software related to the operation and use of the electronic device 200. For example, the storage component 240 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optical disk, and / or a solid-state disk), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cassette, a magnetic tape, and / or another type of non-volatile computer-readable medium, and a corresponding drive.

[0042] Input components 250 include components that allow electronic device 200 to receive information, such as through user input, such as a touch screen display, a keyboard, a keypad, a mouse, buttons, switches, and / or a microphone. Additionally or alternatively, input components 250 may include sensors for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or an actuator). Output components 260 include components that provide output information from electronic device 200, such as a display, a speaker, and / or one or more light emitting diodes (LEDs).

[0043] The communication interface 270 includes a transceiver-like component (e.g., a transceiver and / or a separate receiver and transmitter) that enables the electronic device 200 to communicate with other devices, for example, via a wired connection, a wireless connection, or a combination of wired and wireless connections. The communication interface 270 can allow the electronic device 200 to receive information from another device and / or provide information to another device. For example, the communication interface 270 can include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, etc.

[0044] The electronic device 200 can perform one or more of the processes described herein. The electronic device 200 can perform these processes in response to the processor 220 executing software instructions stored by a non-volatile computer-readable medium (e.g., memory 230 and / or storage component 240). Computer-readable media is defined herein as a non-volatile memory device. A memory device includes storage space within a single physical storage device or storage space distributed across multiple physical storage devices.

[0045] The software instructions may be read into the memory 230 and / or storage component 240 from another computer-readable medium or from another device via the communication interface 270. When executed, the software instructions stored in the memory 230 and / or storage component 240 may cause the processor 220 to perform one or more of the processes described herein. Additionally or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more of the processes described herein. Accordingly, the embodiments described herein are not limited to any specific combination of hardware circuitry and software.

[0046] supply Figure 2 The number and arrangement of components shown are examples. Figure 2 The electronic device 200 may include more components, fewer components, different components, or components arranged differently than those shown. Additionally or alternatively, one or more components of the electronic device 200 may perform one or more functions described as being performed by another group of components of the electronic device 200.

[0047] In some embodiments of the present application, a NBMP system 300 is provided. Figure 3 The NBMP system 300 includes a NBMP source 310 , a NBMP workflow manager 320 , a function repository 330 , one or more media processing devices 350 , a media source 360 , and a media sink 370 .

[0048] NBMP source 310 can receive instructions from third-party device 380, communicate with NBMP workflow manager 320 via NBMP workflow API 392, and communicate with function repository 330 via function discovery API 391. For example, NBMP source 310 can send workflow description documents (WDDs) to NBMP workflow manager 320 and read function descriptions of various functions stored in function repository 330. These functions can include media processing functions stored in memory of function repository 330, such as media decoding, feature point extraction, camera parameter extraction, projection methods, seam information extraction, blending, post-processing, and encoding. NBMP source 310 can include or be implemented by at least one processor and memory storing code for causing the at least one processor to execute the functions of NBMP source 310.

[0049] The NBMP source 310 may request the NBMP workflow manager 320 to create a workflow including a task 352 by sending a workflow descriptor document to the NBMP workflow manager 320, wherein the task 352 will be executed by one or more media processing devices 350. The workflow descriptor document may include multiple descriptors, each of which may include multiple parameters.

[0050] For example, NBMP source 310 may select a function stored in function repository 330 and send a workflow descriptor document to NBMP workflow manager 320. The workflow descriptor document includes various descriptors describing details such as input and output data, required functions, and workflow requirements. The workflow descriptor document may further include a set of task descriptions and a connection mapping of the inputs and outputs of tasks 352 to be executed by one or more media processing devices 350. When NBMP workflow manager 320 receives this information from NBMP source 310, it may instantiate tasks based on the function names and connect the tasks according to the connection mapping to create a workflow.

[0051] Alternatively or additionally, NBMP source 310 may request NBMP workflow manager 320 to create a workflow using a set of keywords. For example, NBMP source 310 may send a workflow descriptor document including the set of keywords to NBMP workflow manager 320, which may then use the set of keywords to search for appropriate functions stored in function repository 330. Upon receiving this information from NBMP source 310, NBMP workflow manager 320 may use the keywords specified in the process descriptor of the workflow descriptor document to search for appropriate functions, and may use other descriptors in the workflow descriptor document to provide and connect tasks to create a workflow.

[0052] The NBMP workflow manager 320 can communicate with the function repository 330 via a function discovery API 393, which can be the same as or different from the function discovery API 391, and can communicate with one or more media processing devices 350 via an NBMP task API 394. The NBMP workflow manager 320 can include or be implemented by at least one processor and a memory storing code for causing the at least one processor to perform the functions of the NBMP workflow manager 320.

[0053] The NBMP workflow manager 320 can use the NBMP task API 394 to set up, configure, manage, and detect one or more tasks 352 of a workflow, where the tasks 352 of the workflow can be executed by one or more media processing devices 350. In an embodiment, the NBMP workflow manager 320 can use the NBMP task API 394 to update and destroy tasks 352. To configure, manage, and detect the tasks 352 of a workflow, the NBMP workflow manager 320 can send messages, such as requests, to one or more media processing devices 350, where each message can have several descriptors, each of which can include parameters. Tasks 352 can each include a media processing function 354 and a configuration 353 for the media processing function 354.

[0054] In some embodiments, after receiving a workflow descriptor document from an NBMP source 310 that does not include a task list (e.g., includes a keyword list instead of a task list), the NBMP workflow manager 320 may select a task based on the description of the task in the workflow descriptor document, searching the function repository 330 via the function discovery API 393 to find an appropriate function to run as a task 352 of the current workflow. For example, the NBMP workflow manager 320 may select a task based on keywords provided in the workflow descriptor document. After identifying the appropriate function using keywords or a set of task descriptions provided by the NBMP source 310, the NBMP workflow manager 320 may use the NBMP task API 394 to configure the selected task in the workflow. For example, the NBMP workflow manager 320 may extract configuration data from the information received from the NBMP source and configure the task 352 based on the extracted configuration data.

[0055] The one or more media processing devices 350 may be configured to receive media content from a media source 360, process the media content according to a workflow including tasks 352 and created by the NBMP workflow manager 320, and output the processed media content to a media sink 370. The one or more media processing devices 350 may each include or be implemented by at least one processor and a memory storing code for causing the at least one processor to perform the functions of the media processing device 350.

[0056] Media source 360 may include a memory for storing media and may be integrated with or separate from NBMP source 310. In some embodiments, NBMP workflow manager 320 notifies NBMP source 310 when a workflow is ready, and media source 360 may transmit the media content to one or more media processing devices 350 based on the notification that the workflow is ready.

[0057] The media receiving end 370 may include or be implemented by at least one processor and at least one display, where the at least one display is used to display the media processed by the one or more media processing devices 350 .

[0058] The third-party device 380 may include or be implemented by at least one processor and a memory storing codes for causing the at least one processor to execute the functions of the third-party device 380 .

[0059] As discussed above, messages from NBMP source 310 to NBMP workflow manager 320 (e.g., requesting the creation of a workflow description document for a workflow), and messages from NBMP workflow manager 320 to one or more media processing devices 350 (e.g., messages initiating the execution of a workflow), may include several descriptors, each of which includes multiple parameters. In embodiments, communications between any components of NBMP system 300 using an API may include several descriptors, each of which includes multiple parameters.

[0060] refer to Figure 4 , depicts a block diagram of a 3GPP FLUS architecture 400 according to an embodiment of the present disclosure. The 3GPP FLUS architecture 400 may include a first environment 402 (e.g., a user environment including one or more user devices) and a second environment 404 (e.g., a user environment or a network). The first environment 402 may include one or more acquisition devices 406 and a FLUS source 408. The FLUS source 408 may include a control source 410, a media source 412, an auxiliary receiver 414, and a remote control target 416. The second environment 404 may include a FLUS receiver 418, an auxiliary transmitter 420, and a remote controller 422. The FLUS receiver 418 may include a control receiver 424 and a media receiver 426.

[0061] Any number of acquisition devices 406, control sources 410, media sources 412, auxiliary receivers 414, and remote control targets 416 can be implemented by the same or different at least one processor and memory storing computer instructions of the first environment 402. In addition, any number of control receivers 424, media receivers 426, auxiliary transmitters 420, and remote controllers 422 can be implemented by the same or different at least one processor and memory storing computer instructions of the second environment 404.

[0062] Communication between the first environment 402 and the second environment 404 can be provided by, for example, a network. For example, communication can be provided via FC links, FU links, FA links, and F-RC links, which can be, for example, APIs. The FC link can represent the endpoint of the communication path between the control source 410 and the control receiver 424. The FU link can represent the endpoint of the communication path between the media source 412 and the media receiver 426. The FA link can represent the endpoint of the communication path between the auxiliary receiver 414 and the auxiliary transmitter 420. The F-RC link can represent the endpoint of the communication path between the remote control target 416 and the remote controller 422.

[0063] The FLUS source 408 can receive media content from one or more capture devices 406 within the first environment 402 or connected to the first environment and forward the media content to the FLUS sink 426. The FLUS sink 426 can forward the media content to decoding and rendering functions within the second environment 404 and / or to processing or distribution sub-functions.

[0064] The control source 410 can control the control sink 424 via the FC link to process the received media content for subsequent downstream distribution and can select a FLUS media instance. The FC link can represent interactions associated with creating and modifying the configuration of the FLUS sink 418. For example, the FC link can allow the control source 410 to select a FLUS media instance, provide static metadata associated with each media session in the FLUS session, and select and configure processing and distribution sub-functions.

[0065] The media source 412 and the media sink 426 can establish one or more media sessions and subsequent media data transmission via media streams using the FU link. A FLUS media instance can be defined as part of a FLUS session. Multiple media streams can be established for a FLUS session. A media stream can contain media components of one or more media content types (e.g., audio and / or video). A FLUS session can be composed of one or more media streams, each of which contains, for example, the same content type (e.g., multiple video media streams).

[0066] The auxiliary transmitter 420 can send an auxiliary message to the auxiliary receiver 414 via the FA link. The FLUS source 408 can be configured to change the behavior of the FLUS media function within the FLUS source 408 (e.g., the media sending behavior of the media source) based on the auxiliary message. The auxiliary information in the auxiliary message can relate to, for example, network-related conditions, ratings or engagement information from content recipients, or user preference data. Since there is currently no ratings for the uplink live stream content, an exemplary recommendation issued by the auxiliary receiver 414 to the media source 412 can be to upload only the first 5 seconds of the video to the FLUS receiver 418.

[0067] Remote controller 422 can send control messages to remote control target 416 via the F-RC link. The control messages can include, for example, commands to start or stop media upstream processing in FLUS source 408. FLUS source 408 can be configured to change the behavior of media source 412 based on the control messages. Remote controller 422 can provide media sink information to FLUS source 408 via the F-RC link, select a FLUS media instance, and determine capture device settings and other FLUS source parameters.

[0068] The embodiments may involve various scenarios for deploying NBMP using 5G FLUS. The embodiments may provide a general architecture and its variants, as well as example call flows for each scenario.

[0069] As mentioned above, in the NBMP standard, an NBMP source is an entity that provides workflow descriptions to a workflow manager for the creation, execution, management, and monitoring of media workflows. Interaction between the NBMP source and the workflow manager occurs through a set of NBMP operational APIs. For the 3GPP FLUS protocol, the source device of a media stream establishes an uplink session with the sink over the network. The FLUS API allows the source device to control the session and the sink to provide feedback or remotely control the source device.

[0070] The current 3GPP FLUS protocol supports the use of NBMP Workflow Description Documents (WDDs) as part of the session control update for source devices. However, it does not cover practical deployment scenarios for using NBMP with 5G FLUS.

[0071] For deploying NBMP using FLUS, embodiments may extend the above architecture. For example, Figure 5 An embodiment of an architecture 500 is shown, which extends the architecture 400 by including an application UA 504 in the first environment 402, a FLUS control receiver 424 and a FLUS media receiver 426 in the receiving end 502 (which may be a receiving end device), and an application EA 508 in an external application server 506 that communicates with the first environment 402 and the receiving end 502. To avoid unnecessary repetition, redundant descriptions are omitted.

[0072] Furthermore, architecture 500 shows links F1, F2, F3, F5, and F7, which may be, for example, APIs. Figure 5 As shown, link F1 may represent an endpoint of a communication path between application EA 508 and FLUS control receiver 424. Link F2 may represent an endpoint of a communication path between FLUS media receiver 426 and another element or device. Link F3 may represent an endpoint of a communication path between FLUS control receiver 424 and FLUS media receiver 426. Link F5 may represent an endpoint of a communication path between FLUS control source 410 and application UA 504. Link F7 may represent an endpoint of a communication path between FLUS media source 412 and application UA 504. Link F8 may represent an endpoint of a communication path between application EA 508 and application UA 504.

[0073] Figures 6 to 10 Shown based on Figure 5Different deployment scenarios of the common architecture.

[0074] Figure 6 An architecture 600 is shown, wherein Figure 5 Elements of the Architecture 500 Figure 3 To avoid unnecessary repetition, redundant descriptions are omitted. Figure 6 As shown in the architecture 600, the external application server 506 includes an NBMP source 310, an NBMP workflow manager 320, and a media processing entity 350. Figure 6 As shown, architecture 600 includes NBMP / FLUS media source 602, which may correspond to one or more of NBMP media source 360 and FLUS media source 412, and source server 604, which may correspond to NBMP media sink 370. Furthermore, in an embodiment, application EA 508 may correspond to third-party entity 380, link N1 may represent an endpoint of a communication path between application EA 508 and NBMP source 310, link N2 may correspond to NBMP workflow API 392, and link N3 may correspond to NBMP task API 394.

[0075] like Figure 6 As shown, an example of the steps for establishing, operating, and releasing a FLUS-NBMP session using architecture 600 is as follows:

[0076] 1. Application UA504 sends a request to application EA508 to start a real-time session via link F8.

[0077] 2. Application EA508 requests the FLUS receiver list from the receiver discovery server (not shown).

[0078] 3. The receiving end finds that the server responds to the request of application EA508.

[0079] 4. The application EA 508 selects the receiver 502 and finds its FLUS media receiver 426 address.

[0080] 5. Apply EA508 to retrieve the user profile and determine the resources required to run the service.

[0081] 6. Application EA508 requests NBMP source 310 to start the NBMP workflow.

[0082] 7. The NBMP source 310 builds a WDD and requests the NBMP workflow manager 320 to instantiate a workflow.

[0083] 8. The NBMP workflow manager 320 discovers various MPEs and finds a sufficient number of MPEs to run the workflow.

[0084] 9. The NBMP workflow manager 320 instantiates the workflow.

[0085] 10. The NBMP Workflow Manager 320 responds to the NBMP Source 310 with the updated WDD.

[0086] 11. The NBMP source 310 informs the application EA 508 of the workflow instantiation.

[0087] 12. The EA 508 responds to the UA 504 with the receiver control information and the media receiver information.

[0088] 13. The application UA 504 requests the FLUS control source 410 to establish a FLUS session.

[0089] 14. The FLUS control source 410 establishes a FLUS session and informs the application UA 504 .

[0090] 15. The application UA504 starts receiving content.

[0091] 16. The session runs.

[0092] …

[0093] …

[0094] …

[0095] 17. Application UA504 requests application EA508 to end the session.

[0096] 18. Application EA 508 requests NBMP source 310 to stop the NBMP workflow.

[0097] …

[0098] 19. The NBMP source 310 confirms stopping the NBMP session.

[0099] 20. The application EA508 notifies the application UA504 to stop the workflow.

[0100] 21. The application UA 504 requests the FLUS control receiver 424 to stop the FLUS session.

[0101] …

[0102] Table 1 shows Figure 6 Standard interfaces required in the scene.

[0103] Table 1 Standard APIs required by NBMP in application servers

[0104]

[0105] Figure 7An architecture 700 is shown, wherein Figure 5 Elements of the Architecture 500 Figure 3 To avoid unnecessary repetition, redundant descriptions are omitted. Figure 7 As shown, in architecture 700 , the external application server 506 includes an NBMP source 310 and an NBMP workflow manager 320 , and the receiving end 502 includes a media processing entity 350 .

[0106] like Figure 7 As shown, examples of steps for establishing, operating, and releasing a FLUS-NBMP session using architecture 700 are as follows:

[0107] 1. Application UA 504 sends a request to application EA 508 to start a real-time session via link F8.

[0108] 2. The Application EA 508 retrieves the user profile and determines the resources required to run the service.

[0109] 3. Application EA 508 requests a list of FLUS receivers and their capabilities from a receiver discovery server (not shown).

[0110] 4. The application EA 508 selects a receiver 502 that can run the workflow in its MPE 350 and looks up its MPE address and MPE API in its capabilities.

[0111] 5. The application EA 508 requests the NBMP source 310 to start the NBMP workflow using the FLUS media sink 426 address.

[0112] 6. The NBMP source 310 builds a WDD and requests the NBMP workflow manager 320 to instantiate a workflow using the assigned MPE 350 .

[0113] 7. The NBMP Workflow Manager 320 instantiates the workflow in the assigned MPE 350 .

[0114] 8. The NBMP Workflow Manager 320 responds to the NBMP Source 310 with the updated WDD.

[0115] 9. The NBMP source 310 informs the application EA 508 of the workflow instantiation.

[0116] 10. Application EA508 responds to application UA504 with receiver control and media receiver information.

[0117] 11. The application UA 504 requests the FLUS control source 410 to establish a FLUS session.

[0118] 12. The FLUS control source 410 establishes a FLUS session and informs the application UA 504 .

[0119] 13. The application UA 504 starts receiving content.

[0120] 14. The session runs.

[0121] …

[0122] …

[0123] …

[0124] 15. Application UA504 requests application EA508 to end the session.

[0125] 16. Application EA 508 requests NBMP source 310 to stop the NBMP workflow.

[0126] …

[0127] 17. The NBMP source 310 confirms stopping the NBMP session.

[0128] 18. The application EA508 notifies the application UA504 to stop the workflow.

[0129] 19. The application UA 504 requests the FLUS control receiver 424 to stop the FLUS session.

[0130] …

[0131] In the above, the call flow in No. 2-9 is different from the previous scenario.

[0132] Table 2 shows Figure 7 Standard interfaces required in the scene.

[0133] Table 2 Standard APIs required when NBMP is located in the application server and MPE is located on the receiving end

[0134]

[0135] *N3 can be a closed API implemented by an application provider-operator agreement.

[0136] Figure 8 An architecture 800 is shown, wherein Figure 5 Elements of the Architecture 500 Figure 3 To avoid unnecessary repetition, redundant descriptions are omitted. Figure 8 As shown, in architecture 800 , the external application server 506 includes an NBMP source 310 , and the receiving end 502 includes a media processing entity 350 and an NBMP workflow manager 320 .

[0137] like Figure 8 As shown, examples of steps for establishing, operating, and releasing a FLUS-NBMP session using architecture 800 are as follows:

[0138] 1. Application UA 504 sends a request to application EA 508 to start a real-time session via link F8.

[0139] 2. The Application EA 508 retrieves the user profile and determines the resources required to run the service.

[0140] 3. Application EA 508 requests a list of FLUS receivers and their capabilities from a receiver discovery server (not shown).

[0141] 4. The application EA 508 selects a receiver 502 that can run the workflow in its MPE 350 and finds its NBMP workflow manager 320 and FLUS media receiver 426 addresses in the receiver capabilities.

[0142] 5. The application EA 508 requests the NBMP source 310 to start the NBMP workflow using the FLUS media sink 426 address.

[0143] 6. The NBMP source builds the WDD and requests the NBMP workflow manager 320 to instantiate the workflow using the assigned MPE 350 .

[0144] 7. The NBMP Workflow Manager 320 instantiates the workflow in the assigned MPE 350 .

[0145] 8. The NBMP Workflow Manager 320 responds to the NBMP Source 310 with the updated WDD.

[0146] 9. The NBMP source 310 informs the application EA 508 of the workflow instantiation.

[0147] 10. Application EA 508 responds to application UA 504 with receiver control and media receiver information.

[0148] 11. The application UA 504 requests the FLUS control source 410 to establish a FLUS session.

[0149] 12. The FLUS control source 410 establishes a FLUS session and informs the application UA 504 .

[0150] 13. The application UA 504 starts receiving content.

[0151] 14. The session runs.

[0152] …

[0153] …

[0154] …

[0155] 15. Application UA 504 requests application EA 508 to end the session.

[0156] 16. Application EA 508 requests NBMP source 310 to stop the NBMP workflow.

[0157] …

[0158] 17. The NBMP source 310 confirms stopping the NBMP session.

[0159] 18. Application EA 508 informs application UA 504 to stop the workflow.

[0160] 19. The application UA 504 requests the FLUS control receiver 424 to stop the FLUS session.

[0161] …

[0162] In the above, the call flow in No. 4-9 is different from the previous scenario.

[0163] Table 3 shows Figure 8 Standard interfaces required in the scene.

[0164] Table 3 Standard APIs required when NBMP is located in the application server and the NBMP workflow manager and MPE are located on the receiving end

[0165]

[0166] Figure 9 An architecture 900 is shown, wherein Figure 5 Elements of the Architecture 500 Figure 3 To avoid unnecessary repetition, redundant descriptions are omitted. Figure 9 As shown, in architecture 900 , the FLUS control source 410 includes an NBMP source 310 , and the receiving end 502 includes a media processing entity 350 and an NBMP workflow manager 320 .

[0167] like Figure 9 As shown, examples of steps for establishing, operating, and releasing a FLUS-NBMP session using architecture 900 are as follows:

[0168] 1. Application UA 504 sends a request to application EA 508 to start a real-time session via link F8.

[0169] 2. Apply EA508 to retrieve the user profile and determine the resources required to run the service.

[0170] 3. Application EA 508 requests a list of FLUS receivers and their capabilities from a receiver discovery server (not shown).

[0171] 4. The application EA 508 selects a receiver 502 that can run the workflow in its MPE 350 and finds its NBMP workflow manager 320 and FLUS media receiver 426 addresses in the receiver capabilities.

[0172] 5. The application EA 508 responds to the UE using the complete URL or relative URL of the NBMP workflow manager 320 through the FLUS control receiving terminal 424.

[0173] 6. The application UA 504 requests the FLUS control source 410 to establish a FLUS session.

[0174] 7. The FLUS control source 410 establishes a FLUS session and informs the application UA 504 .

[0175] 8. The EA requests the NBMP source 310 to start the workflow.

[0176] 9. The NBMP source 310 builds a WDD and requests the NBMP workflow manager 320 (directly or through the FLUS control receiver 424) to instantiate the workflow.

[0177] 10. The NBMP workflow manager 320 instantiates the workflow in the MPE 350 .

[0178] 11. The NBMP Workflow Manager 320 responds to the NBMP Source 310 with the updated WDD.

[0179] 12. The NBMP source 310 informs the application UA 504 of the workflow instantiation.

[0180] 13. The application UA 504 starts receiving content.

[0181] 14. The session runs.

[0182] …

[0183] …

[0184] …

[0185] 15. The application UA 504 requests the FLUS control source 410 to stop the session.

[0186] 16. The NBMP source 310 requests the NBMP workflow manager 320 to stop the workflow.

[0187] 17. The FLUS control source 410 requests to stop the FLUS session.

[0188] …

[0189] In the above, the call flows in No. 4-9, 11-12, and 15-17 are different from the previous scenarios.

[0190] Table 4 shows Figure 9 Standard interfaces required in the scene.

[0191] Table 4 NBMP source NBMP is located in the FLUS control source and the workflow manager and MPE are located in the receiving end

[0192]

[0193] * With the support of NBMP Workflow Manager API

[0194] Table 5 shows a summary of the deployment scenarios.

[0195] Table 5: Summary of deployment scenarios

[0196]

[0197]

[0198] *N3 can be a closed API implemented by an application provider-operator agreement

[0199] ** With the support of NBMP Workflow Manager API

[0200] Therefore, embodiments may provide a method for deploying NBMP workflow management in a 5G FLUS environment, considering four different scenarios, including: a) NBMP located in an application server; b) NBMP located in an application server and an MPE located in a receiving end; c) NBMP source located in an application server and an NBMP workflow manager and MPE located in a receiving end; and d) NBMP source located in a FLUS control source and an NBMP workflow manager and MPE located in a receiving end. In each scenario, the NBMP module can be implemented in a different module of the FLUS architecture. For each scenario, an API between NBMP and FLUS is defined, where the API is divided into an API based on the NBMP standard, an API based on the 3GPP FLUS standard, an internal API for each module, and a dedicated API between service providers and operators.

[0201] Furthermore, embodiments can provide methods for each of the four scenarios described above, including separate call flows for establishing, managing, and tearing down NBMP-FLUS joint sessions. The call flows, NBMP, and FLUS sessions for each scenario are configured. Appropriate information is exchanged via the APIs defined above to establish and manage the joint session. FLUS is used to transfer content from the device to the network, and then the content is processed in the cloud or edge service using the NBMP standard.

[0202] Furthermore, embodiments provide interfaces, workflows, and processes for discovering FLUS media network processing capabilities using a 5G edge data architecture. This functionality allows external application servers to learn about the current capabilities of the 5G network before requesting to set up network-based processing using FLUS.

[0203] The current 3GPP FLUS protocol supports the use of the NBMP Workflow Description Document (WDD) as part of the source device's session control update. However, it does not address the issue of discovering the network processing capabilities of different edge servers for FLUS services.

[0204] Figure 10 1 is a block diagram of a media architecture 1000 for streaming media. In an embodiment, the media architecture 1000 can be used for uplink streaming or downlink streaming. A 5G Media Streaming Uplink (5GMS) application provider 1001 can use 5GMS for streaming services. The 5GMS application provider 1001 can provide a 5GMS-aware application 1002 on a user equipment UE 1003, thereby utilizing a 5GMS client 1004 and network functions through interfaces and APIs defined in 5GMS. The 5GMS application server (AS) can be an AS dedicated to 5G streaming media. The 5GMS client 1004 can be an internal function of the UE 1003 dedicated to 5G streaming media.

[0205] The 5GMS Application Function (AF) 1006 and the 5GMS AS 1005 can be Data Network (DN) 1007 functions. Functions in a trusted DN can be trusted by the operator network. Therefore, the AF in a trusted DN can communicate directly with all 5G core functions. Functions in external DNs can only communicate with 5G core functions through the Network Exposure Function (NEF) 1008 using link N33.

[0206] The media architecture 1000 can connect the internal functions of the UE 1003 and the relevant network functions for 5G media uplink streaming. Therefore, the media architecture 1000 can include many functions. For example, the 5GMS client 1004 on the UE 1003 can be the initiator of the 5GMS service that can be accessed through the interface / API. The 5GMS client 1004 can include two sub-functions, namely the Media Session Handler (MSH) 1009 and the Media Stream Dispatcher 1010. The MSH 1009 can communicate with the 5GMS AF 1006 to establish, control and support the delivery of the media session. The MSH 1009 can expose an API that can be used by the 5GMS-aware application 1002. The media streamer 1010 can communicate with the 5GMS AS 1005 to stream media content and provide services for media acquisition and streaming, as well as the MSH 1009 for media session control, to the 5GMS-aware application 1002. The 5GMS-aware application 1002 can control the 5GMS client 1003 by implementing logic specific to external applications or content service providers and allowing media sessions to be established. The 5GMS AS 1005 can host 5G media functions. The 5GMS application provider 1001 can be an external application or content-specific media function, such as using 5GMS media storage, consumption, transcoding, and redistribution to stream media from the 5GMS-aware application 1002. The 5GMS AF 1006 can provide various control functions to the MSH 1009 and / or the 5GMS application provider 1001 on the UE 1003. The 5GMS AF 1006 can relay or initiate requests for different policy or charging functions (PCF) or interact with other network functions.

[0207] The media architecture 1000 may include many different interfaces. For example, link M1 may be a 5GMS provided API exposed by the 5GMS AF 1006 for using the media architecture 1000 and obtaining feedback. Link M2 may be a 5GMS published API exposed by the 5GMS AS 1005, which is used when the 5GMS AS 1005 in a trusted DN (such as DN 1007) is selected to receive content from a streaming service. Link M3 may be an internal API for exchanging information for content hosting on the 5GMS AS 1005 inside a trusted DN (such as DN 1007). Link M4 may be an uplink streaming API exposed by the 5GMS AS 1023 to the media streamer 1010 for streaming media content. Link M5 may be a media session handling API exposed by the 5GMS AF 1005 to the media session handler for media session handling, control, and assistance including appropriate security mechanisms (such as authorization and authentication). Link M6 may be a media session handling API for UE 1003 exposed by MSH 1009 to 5GMS-aware application 1002 for utilizing 5GMS functions. Link M7 may be a UE media streamer API exposed by media streamer 1010 to 5GMS-aware application 1002 and MSH 1009 for utilizing media streamer 1010. Link M8 may be an application API for information exchange between 5GMS-aware application 1002 and 5GMS application provider 1001, for example, providing service access information to 5GMS-aware application 1002.

[0208] Figure 11 1 is a schematic diagram of a 5G edge network architecture 1100 according to an embodiment. An edge data network (EDN) 1101 is a local data network. An edge application server (EAS) 1102 and an edge enabler server (EES) 1103 are included in the EDN 1101. An edge configuration server (ECS) 1104 provides configuration related to the EES 1103, including detailed information about the EDN 1101 hosting the EES 1103. A UE 1105 includes an application client (AC) 1106 and an edge enabler client (EEC) 1107. The EAS 1102, EES 1103, and ECS 1104 can interact with a 3GPP core network 1108.

[0209] EES1103 provides the support functions required by EAS1102 and EEC 1107. The functions of EES1103 may include: providing configuration information to EEC1107 to implement application data traffic exchange with EAS; supporting API caller functions and API exposure functions, such as those specified in 3GPP TS23.222; interacting with the 3GPP core network 1108 to access network functions directly (e.g., through PCF) or indirectly (e.g., through Service Capability Exposure Function (SCEF) / NEF / SCEF+NEF); supporting application context transfer functions; supporting the exposure of 3GPP network and service capabilities to EAS1102 via Link Edge-3; supporting registration functions (i.e., registration, update, and deregistration) of EEC 1107 and EAS; and supporting the on-demand triggering of EAS1102 instantiation.

[0210] The EEC 1107 provides support functions required by the AC. The functions of the EEC 1107 may include: retrieving and providing configuration information to exchange application data traffic with the EAS 1102; and discovering available EASs 1102 in the EDN 1101.

[0211] ECS 1104 provides the support functions required for EEC 1107 to connect to EES 1103. The functions of ECS 1104 are: providing edge configuration information to EEC 1107, such as information used for EEC 1107 to connect to EES 1103 (for example, service area information suitable for LADN); and information used to establish a connection with EES 1103 (for example, URI); supporting EES 1103 registration functions (i.e., registration, update, and deregistration); supporting API caller functions and API exposure functions specified in 3GPP TS 23.222; and interacting with the 3GPP core network 1108 to access network functions directly (for example, PCF) or indirectly (for example, through SCEF / NEF / SCEF+NEF).

[0212] AC 1106 is an application in UE 1105 that performs client functions.

[0213] EAS 1102 is an application server that performs server functions within EDN 1101. AC 1106 connects to EAS 1102 to leverage the services of an application, leveraging edge computing. An application's server functions may be available only as EAS 1102. However, certain server functions may also be available both at the edge and in the cloud, as EAS 1102 and as application servers in the cloud. The server functions of EAS 1102 and its corresponding cloud application server may be the same or different. If they are different, the application data traffic exchanged with the AC may also be different. EAS 1102 can consume 3GPP core network 1108 capabilities in different ways. For example, if it is a trusted entity of 3GPP core network 1108, it can directly call 3GPP core network 1108 function APIs; it can call 3GPP core network 1108 capabilities through EES 1103; and it can call 3GPP core network 1108 capabilities through a capability exposure function (i.e., SCEF or NEF).

[0214] The architecture 1100 may include multiple different interfaces for enabling edge applications, which may be referred to as reference points. For example, the EDGE-1 link may be a reference point that enables interaction between the EES 1103 and the EEC 1107. It supports: registration and deregistration of the EEC 1107 with the EES 1103; retrieval and provisioning of EAS 1102 configuration information; and discovery of EAS 1102 available in the EDN 1101.

[0215] The EDGE-2 link can be a reference point for implementing interactions between the EES 1103 and the 3GPP core network 1108. It supports access to 3GPP core network 1108 functions and APIs to retrieve network capability information, for example, through the SCEF and NEF APIs defined in 3GPP TS 23.501, 3GPP TS 23.502, 3GPP TS 29.522, 3GPP TS 23.682, and 3GPP TS 29.122, or using the EES 1103 deployed within the MNO trust domain (see 3GPP TS 23.501 Section 5.13, 3GPP TS 23.503, 3GPP TS 23.682). Considering different deployment models, the EDGE-2 link can reuse 3GPP reference points or interfaces of EPS or 5GS.

[0216] The EDGE-3 link can be a reference point that enables interaction between the EES 1103 and the EAS 1102. It supports: registering the EAS 1102 with availability information (e.g., time constraints, location constraints); deregistering the EAS 1102 from the EES 1103; discovering target EAS 1102 information to support application context transfer; providing access to network capability information (e.g., location information, Quality of Service (QoS) related information); and requesting the establishment of a data session with a specific QoS between the AC and the EAS 1102.

[0217] Link EDGE-4 may be a reference point that enables interaction between the ECS 1104 and the EEC 1107. It supports providing edge configuration information to the EEC 1107.

[0218] Link EDGE-5 may be a reference point to enable interaction between the AC and the EEC 1107 .

[0219] The EDGE-6 link may be a reference point to enable interaction between the ECS 1104 and the EES 1103. It supports registering EES 1103 information with the ECS 1104.

[0220] The EDGE-7 link may be a reference point that enables interaction between the EAS 1102 and the 3GPP core network 1108. It supports access to 3GPP core network 1108 functions and APIs to retrieve network capability information, for example, through the SCEF and NEF APIs defined in 3GPP TS 23.501, 3GPP TS 23.502, 3GPP TS 29.522, 3GPP TS 23.682, and 3GPP TS 29.122, or using the EAS 1102 deployed within the MNO trust domain (see 3GPP TS 23.501 Section 5.13, 3GPP TS 23.682). To take into account different deployment models, the EDGE-7 link may reuse 3GPP reference points or interfaces of EPS or 5GS.

[0221] The EDGE-8 link may be a reference point that enables interaction between the EAS 1104 and the 3GPP core network 1108. It supports access to 3GPP core network 1108 functions and APIs to retrieve network capability information, for example, through the SCEF and NEF APIs defined in 3GPP TS 23.501, 3GPP TS 23.502, 3GPP TS 29.522, 3GPP TS 23.682, and 3GPP TS 29.122, and uses the EAS 1104 deployed within the MNO trust domain (see 3GPP TS 23.501 Section 5.13, 3GPP TS 23.682). Considering different deployment models, the EDGE-8 link may reuse 3GPP reference points or interfaces of EPS or 5GS.

[0222] Figure 12 An architecture 1200 is shown, where Figure 11 Elements of the Architecture 1100 and Figure 10 The elements of the architecture 1000 are combined. In order to avoid unnecessary repetition, redundant descriptions are omitted.

[0223] like Figure 12 As shown, link EDGE-9 allows communication between EAS 1102 and 5GMS AP 1001 , link EDGE-10 allows communication between EES 1103 and 5GMS AP 1001 , and link EDGE-11 allows communication between ECS 1104 and 5GMS AP 1001 .

[0224] Figure 13 A process 1300 is shown relating to a call flow for discovering capabilities of an edge data network 1101. The process 1300 can be performed using the architecture 1200 discussed above, the architecture 1000, or any other desired architecture.

[0225] Process 1300 may extend the TS 23.558 API to enable the 5GMS AP 1001 to discover the media capabilities of the edge data network.

[0226] According to process 1300, at operation 13010, 5GMS AP 1001 may send a provisioning request to ECS 1104 using EDGE-11. At operation 13020, ECS 1104 provides 5GMS AP 1001 with a list of EESs 1103 using EDGE-11. At operation 13030, 5GMS AP 1001 requests registration from an EES 1103 included in the list of EESs 1103 using EDGE-10. At operation 13040, EES 1103 registers using EDGE-10 and provides 5GMS AP 1001 with a list and location of EASs 1102. At operation 13050, 5GMS AP 1001 requests service from an EAS 1102 included in the list of EASs 1102 using EDGE-9. In operation 13060 , the EAS 1102 starts running the service and confirms the service to the 5GMS AP 1001 using the EDGE-9 link. The 5GMS AP 1001 connects to the EAS 1102 and uses the service.

[0227] Figure 14 An architecture 1400 is shown, where Figure 5 Elements of the Architecture 500 Figure 12 To avoid unnecessary repetition, redundant descriptions are omitted. Figure 14 As shown, in architecture 1400 , UE 1105 includes a FLUS source 408 , a FLUS control source 410 , and a FLUS media source 412 , and DN 1007 includes a FLUS control receiver 424 and a FLUS media receiver 426 .

[0228] exist Figure 14 In the example architecture 1400 shown elsewhere in this disclosure, the FLUS control receiver 424 and the FLUS media receiver 426, as well as the ECS 1104 and the EES 1103, are logical entities. In implementation, all or part of them may be combined. In addition, the EAS 1102 is a plurality of entities. From the perspective of the FLUS, all EAS 1102 entities are part of the 5GMS application provider 1001. F2 provides the media flow between the FLUS receiver and the 5GMS application provider 1001. Since (part of) the application can run on the EAS 1102, the FLUS media receiver 426 can be connected to the EAS 1102 through the 5GMS application provider 1001.

[0229] In an embodiment, the 5GMS application provider 1001 can directly discover the list and location of the edge application server 1102.

[0230] In an embodiment, the 5GMS application provider 1001 can directly discover the capabilities of edge applications.

[0231] In an embodiment, the 5GMS application provider 1001 can directly request services from the edge application server 1102 and instantiate and use these services.

[0232] In an embodiment, the 5GMS application provider 1001 does not need to perform any of the above functions through the UE 1105.

[0233] In an embodiment, the 5GMS application provider 1001 can use the same resources that the UE 1105 uses to communicate with the edge data network 1007, and no new resources are required.

[0234] In an embodiment, the 5G edge architecture is combined with the FLUS architecture to provide a mechanism for establishing media services on edge servers and providing media streaming between FLUS and edge application servers.

[0235] Thus, embodiments may provide a method of combining a 5G edge data network and FLUS, wherein the two architectures are combined and control and data flows are arranged so that a portion of a media application can run on an edge application server and sessions can be established using standard procedures of the 5G edge network and FLUS architectures.

[0236] Figure 15 is a flow chart of an example process 1500 for MPEG NBMP processing media content. In some implementations, one or more Figure 15 The process blocks in can be performed by one or more elements of any of the above systems or architectures.

[0237] like Figure 15 As shown, process 1500 may include a first application running on an application server receiving a real-time session request from a second application running on a user device separate from the application server to initiate an uplink real-time streaming framework (FLUS) session (block 1502). In an embodiment, the user device may correspond to the first environment 402, and the application server may correspond to the external application server 506.

[0238] like Figure 15 As further shown in FIG. 15 , process 1500 may include obtaining a plurality of FLUS receiver lists (block 1502 ).

[0239] like Figure 15As further shown in FIG. 1 , process 1500 may include selecting a FLUS media receiver running on a receiving device from the plurality of FLUS receivers, the receiving device being separate from the application server and the user device (block 1506). In an embodiment, the FLUS media receiver may correspond to FLUS media receiver 426, and the receiving device may correspond to receiver 502.

[0240] like Figure 15 As further shown in FIG. 15 , process 1500 may include sending a workflow request to a NBMP source to initiate a NBMP workflow associated with the FLUS media sink (block 1508 ). In an embodiment, the NBMP source may correspond to NBMP source 310 .

[0241] like Figure 15 As further shown in FIG. 1 , process 1500 may include sending a response to the second application using the NBMP workflow and the FLUS media sink, the response including session information for establishing a FLUS session (block 1500 ).

[0242] In an embodiment, the application server may include an NBMP source, an NBMP workflow manager, and at least one media processing entity; the receiving device may include a FLUS control receiving end; and the user device may include a FLUS control source and a FLUS media source. In an embodiment, the NBMP workflow manager may correspond to the NBMP workflow manager 320, the at least one media processing entity may correspond to the media processing entity 350, the FLUS control receiving end may correspond to the FLUS control receiving end 424, the FLUS control source may correspond to the FLUS control source 410, and the FLUS media source may correspond to one or more of the NBMP media source 360, the FLUS media source 412, and the NBMP / FLUS media source 602.

[0243] In an embodiment, the workflow description document corresponding to the NBMP workflow can be constructed by the NBMP source and instantiated by the NBMP workflow manager, wherein the session information can include receiver control information corresponding to the FLUS control receiver and media receiver information corresponding to the FLUS media receiver.

[0244] In an embodiment, the application server includes an NBMP source and an NBMP workflow manager, the receiving end device includes a FLUS control receiving end and at least one media processing entity, and the user equipment includes a FLUS control source and a FLUS media source.

[0245] In an embodiment, the FLUS media receiver can be selected based on the capabilities of the at least one media processing entity, the workflow request can include address information of the FLUS media receiver, the workflow description document corresponding to the NBMP workflow can be constructed by the NBMP source and instantiated by the NBMP workflow manager in the at least one media processing entity, and the session information can include receiver control information corresponding to the FLUS control receiver and media receiver information corresponding to the FLUS media receiver.

[0246] In an embodiment, the application server may include the NBMP source, the receiving end device may include a FLUS control receiving end, an NBMP workflow manager and at least one media processing entity, and the user equipment may include a FLUS control source and a FLUS media source.

[0247] In an embodiment, the FLUS media receiver can be selected based on the capabilities of the at least one media processing entity, the workflow request can include the address information of the FLUS media receiver, the workflow description document corresponding to the NBMP workflow is constructed by the NBMP source and instantiated by the NBMP workflow manager in the at least one media processing device, and the session information includes receiver control information corresponding to the FLUS control receiver and media receiver information corresponding to the FLUS media receiver.

[0248] In an embodiment, the receiving end device includes a FLUS control receiving end, an NBMP workflow manager and at least one media processing entity, and the user equipment includes a FLUS control source, a FLUS media source and an NBMP source.

[0249] In an embodiment, the workflow description document corresponding to the NBMP workflow is constructed by the NBMP source and instantiated by the NBMP workflow manager, and the session information includes address information of the NBMP workflow manager.

[0250] In an embodiment, the user equipment includes an edge-enabled client. In an embodiment, the edge-enabled client may correspond to the edge-enabled client 1107 .

[0251] although Figure 15 Example blocks of process 1500 are shown, but in some implementations, process 1500 may include additional blocks, fewer blocks, different blocks, or Figure 15 The process blocks shown in 1500 may be arranged in different ways. Additionally, or alternatively, two or more process blocks of process 1500 may be executed in parallel.

[0252] Furthermore, the disclosed methods can be implemented by processing circuits (e.g., one or more processors or one or more integrated circuits). In one example, one or more processors execute a program stored in a non-volatile computer-readable medium to perform one or more disclosed methods.

[0253] The techniques described above may be implemented as computer software using computer-readable instructions and physically stored on one or more computer-readable media.

[0254] The embodiments of the present disclosure may be used alone or in combination in any order. Further, each embodiment (and method thereof) may be implemented by a processing circuit (e.g., one or more processors or one or more integrated circuits). In one example, one or more processors execute a program stored in a non-volatile computer-readable medium.

[0255] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the embodiments to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the embodiments.

[0256] As used herein, the term component is intended to be broadly interpreted as hardware, firmware, or a combination of hardware and software.

[0257] Although combinations of features are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of possible implementations. In fact, many of these features can be combined in ways not specifically recited in the claims and / or disclosed in the specification. Although each dependent claim listed below may be directly dependent on only one claim, the disclosure of possible implementations includes each dependent claim in combination with every other claim in the claim group.

[0258] Elements, actions or instructions used herein should not be interpreted as critical or necessary unless explicitly described as such. In addition, as used herein, the articles "one" and "an" are intended to include one or more projects and can be used interchangeably with "one or more". In addition, as used herein, the term "set" is intended to include one or more projects (e.g., related projects, unrelated projects, combinations of related and unrelated projects, etc.), and can be used interchangeably with "one or more". When only one project is meant, the term "one" or similar language is used. In addition, as used herein, the terms "having", "having", "containing" etc. are intended to be open terms. Further, the phrase "based on" is intended to mean "based at least in part on", unless otherwise explicitly stated.

Claims

1. A method for processing media content in a Moving Picture Experts Group (MPEG) Network-Based Media Processing (NBMP), the method being executed by at least one processor, the method comprising: A first application running on an application server receives a real-time session request from a second application running on a user device separate from the application server to start an uplink real-time streaming framework (FLUS) session; Get a list of multiple FLUS receivers; Selecting a FLUS media receiver running on a receiver device from the multiple FLUS receivers, wherein the receiver device includes a FLUS control receiver, an NBMP workflow manager, and at least one media processing entity, the receiver device is separate from the application server and the user equipment, and the FLUS media receiver is selected based on capabilities of the at least one media processing entity; Sending a workflow request to an NBMP source to start an NBMP workflow associated with the FLUS media receiver, wherein the workflow request includes address information of the FLUS media receiver, and a workflow description document corresponding to the NBMP workflow is constructed by the NBMP source and instantiated by the NBMP workflow manager; and A response is sent to the second application using the NBMP workflow and the FLUS media receiver, wherein the response includes session information for establishing a FLUS session, wherein the session information includes receiver control information corresponding to the FLUS control receiver and media receiver information corresponding to the FLUS media receiver.

2. The method according to claim 1, wherein The application server includes the NBMP source; The user equipment includes a FLUS control source and a FLUS media source.

3. The method according to claim 1, wherein the user equipment comprises a FLUS control source, a FLUS media source and an NBMP source.

4. The method according to claim 3, wherein: The session information includes address information of the NBMP workflow manager.

5. The method according to claim 1, wherein The user equipment includes an edge-enabled client.

6. An apparatus for processing media content in Moving Picture Experts Group (MPEG) Network-Based Media Processing (NBMP), the apparatus comprising: at least one memory configured to store program code; as well as At least one processor is configured to read the program code and execute according to instructions of the program code, wherein the program code includes: receiving code configured to cause the at least one processor to receive, through a first application running on an application server, a real-time session request from a second application running on a user device separate from the application server, to initiate an uplink real-time streaming framework (FLUS) session; an acquisition code configured to enable the at least one processor to acquire a plurality of FLUS receiving end lists; selecting code configured to cause the at least one processor to select a FLUS media receiver running on a receiver device from the plurality of FLUS receivers, wherein the receiver device includes a FLUS control receiver, an NBMP workflow manager, and at least one media processing entity, the receiver device is separate from the application server and the user equipment, and the FLUS media receiver is selected based on capabilities of the at least one media processing entity; a first sending code configured to cause the at least one processor to send a workflow request to an NBMP source to start an NBMP workflow associated with the FLUS media receiving end, wherein the workflow request includes address information of the FLUS media receiving end, and a workflow description document corresponding to the NBMP workflow is constructed by the NBMP source and instantiated by the NBMP workflow manager; and A second sending code is configured to cause the at least one processor to send a response to the second application using the NBMP workflow and the FLUS media receiver, the response including session information for establishing a FLUS session, wherein the session information includes receiver control information corresponding to the FLUS control receiver and media receiver information corresponding to the FLUS media receiver.

7. The device according to claim 6, wherein The application server includes the NBMP source; the user equipment includes a FLUS control source and a FLUS media source.

8. The apparatus according to claim 6, wherein the user equipment comprises a FLUS control source, a FLUS media source, and an NBMP source.

9. The device according to claim 8, wherein The session information includes address information of the NBMP workflow manager.

10. A non-transitory computer-readable storage medium storing computer instructions, which are configured to, when executed by at least one processor in an apparatus for processing media content in Moving Picture Experts Group (MPEG) Network-Based Media Processing (NBMP), cause the at least one processor to perform a method according to any one of claims 1 to 5.

Images