Method and apparatus for quality of service assurance for WebRTC sessions in 5G networks

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. An apparatus includes at least one transceiver and a processor operably coupled to the at least one transceiver. The controller is configured to receive an expected service level agreement (SLA) for a media service from a service provider, wherein the media service includes a plurality of media streams. The controller is further configured to provide a network slice including media functionality based on the expected SLA. The controller is further configured to configure a media function in the network slice using the traffic prioritization information for each of the plurality of media streams. In addition, the controller is configured to determine a performance of each media stream. The controller is further configured to perform an adjustment of the service parameters based on a determination that the performance of the one or more media streams is below the expected SLA.

Description

Technical Field

[0001] The present disclosure relates to multimedia devices and processes. More specifically, the present disclosure relates to methods and apparatus for ensuring quality of service (QoS) for web real-time communication (WebRTC) sessions in 5G networks. Background Art

[0002] 5G mobile communication technology defines a wide frequency band, making high transmission rates and new services possible, and can be realized not only in "below 6 GHz" frequency bands such as 3.5 GHz, but also in "above 6 GHz" frequency bands (including 28 GHz and 39 GHz) called millimeter waves. In addition, 6G mobile communication technology (called super 5G system) has been considered to be implemented in terahertz (THz) frequency bands (for example, 95 GHz to 3THz frequency bands) in order to achieve a transmission rate fifty times faster than 5G mobile communication technology and ultra-low latency that is one-tenth of 5G mobile communication technology.

[0003] At the beginning of the development of 5G mobile communication technology, in order to support services and meet the performance requirements related to enhanced mobile broadband (eMBB), ultra-reliable and low-latency communications (URLLC) and massive machine type communications (mMTC), standardization of the following technologies is already underway: beamforming and massive MIMO for mitigating radio wave path loss and increasing radio wave transmission distance in millimeter waves; parameter sets supporting dynamic operation for efficient utilization of millimeter wave resources and time slot formats (e.g., operating multiple subcarrier spacings); initial access technology for supporting multi-beam transmission and broadband, definition and operation of bandwidth parts (BWPs); new channel coding methods (e.g., low-density parity-check (LDPC) codes for large amounts of data transmission and polar codes for highly reliable transmission of control information); L2 preprocessing; and network slicing for providing dedicated networks dedicated to specific services.

[0004] Currently, discussions on the improvement and performance enhancement of initial 5G mobile communication technologies are ongoing in view of the services supported by 5G mobile communication technologies, and there is already physical layer standardization on technologies such as: Vehicle-to-Everything (V2X), which assists driving decisions of autonomous vehicles and improves user convenience based on information about the location and status of vehicles transmitted by vehicles; New Radio Unlicensed (NR-U) designed for system operation in compliance with various regulatory-related requirements in unlicensed bands; NR UE energy saving; Non-Terrestrial Network (NTN), which is UE-satellite direct communication for providing coverage in areas where terrestrial network communications are unavailable; and positioning.

[0005] In addition, the air interface architecture / protocol aspects are being standardized for technologies such as: Industrial Internet of Things (IIoT) to support new services through interworking and integration with other industries; Integrated Access and Backhaul (IAB) to provide nodes for network service area expansion by supporting wireless backhaul links and access links in an integrated manner; Mobility enhancements including conditional handover and dual active protocol stack (DAPS) handover; and two-step random access (2-step RACH for NR) to simplify the random access process. System architecture / services for the following technologies are also being standardized: 5G baseline architecture (e.g., service-based architecture or service-based interface) for combining network function virtualization (NFV) and software-defined network (SDN) technologies; and mobile edge computing (MEC) for receiving services based on UE location.

[0006] With the commercialization of 5G mobile communication systems, the number of connected devices, which has been growing exponentially, will be connected to the communication network, and it is therefore expected that there will be a need to enhance the functions and performance of 5G mobile communication systems and the integrated operation of connected devices. To this end, new research related to the following technologies is planned: Extended Reality (XR) for effective support of Augmented Reality (AR), Virtual Reality (VR), Mixed Reality (MR), etc.; Improving 5G performance and reducing complexity by utilizing Artificial Intelligence (AI) and Machine Learning (ML); AI service support; Metaverse service support and drone communication.

[0007] Furthermore, such developments in 5G mobile communication systems will serve not only as a basis for developing new waveforms for providing coverage in the terahertz band for 6G mobile communication technology; multi-antenna transmission technologies such as full-dimensional MIMO (FD-MIMO), array antennas, and large antennas; metamaterial-based lenses and antennas for improving the coverage of terahertz band signals; high-dimensional spatial multiplexing technologies using orbital angular momentum (OAM); and reconfigurable smart surfaces (RIS), but will also serve as a basis for developing full-duplex technologies for increasing the frequency efficiency of 6G mobile communication technology and improving system networks; AI-based communication technologies for achieving system optimization by leveraging satellites and AI (artificial intelligence) from the design stage and internalizing end-to-end AI support functions; and next-generation distributed computing technologies for implementing services at a complexity level that exceeds the limits of UE operating capabilities by utilizing ultra-high-performance communication and computing resources. Summary of the invention

[0008] Technical issues

[0009] Currently, there is a need to enhance quality of service assurance for WebRTC sessions in wireless communication systems.

[0010] Technical Solution

[0011] The present disclosure provides a method and apparatus for ensuring QoS for WebRTC sessions in a 5G network.

[0012] In a first embodiment, an apparatus includes a communication interface and a processor operably coupled to the communication interface. The processor is configured to receive an expected service level agreement (SLA) for a media service from a service provider, wherein the media service includes a plurality of media streams. The processor is further configured to provide a network slice including a media function based on the expected SLA. The processor is further configured to configure the media function in the network slice using traffic prioritization information for each of the plurality of media streams. Additionally, the processor is configured to determine a performance of each of the media streams. The processor is further configured to perform an adjustment of a service parameter based on determining that the performance of one or more media streams is below the expected SLA.

[0013] In a second embodiment, a method includes receiving an expected service level agreement (SLA) for a media service from a service provider, wherein the media service includes a plurality of media flows. The method also includes providing a network slice including a media function based on the expected SLA. The method also includes configuring the media function in the network slice using traffic prioritization information for each of the plurality of media flows. The method also includes determining a performance of each of the media flows, and performing an adjustment of a service parameter based on determining that the performance of one or more media flows is below the expected SLA.

[0014] Other technical features may be apparent to those skilled in the art from the following drawings, descriptions and claims.

[0015] Before the following detailed description, it may be advantageous to set forth the definitions of certain words and phrases used throughout this patent document.The term "connection" and its derivatives refer to any direct or indirect communication between two or more elements, whether or not these elements are in physical contact with each other.The terms "transmit", "receive" and "communication" and their derivatives cover direct and indirect communication.The terms "include" and "includes" and their derivatives mean including but not limited to.The term "or" is inclusive, meaning and / or.The phrase "associated with..." and its derivatives mean including, included in, interconnected with, included in, included in, connected to, connected to, connected to, connected to, connected to, communicated with, collaborated with, interlaced, paralleled, adjacent to, coupled to, coupled to, coupled to, having ... The phrase "at least one of" when used with a list of items means that different combinations of one or more of the listed items may be used, and only one item in the list may be required. For example, "at least one of A, B, and C" includes any of the following combinations: A, B, C, A and B, A and C, B and C, and A and B and C.

[0016] In addition, the various functions described below may be implemented or supported by one or more computer programs, each of which is formed by a computer-readable program code and embodied in a computer-readable medium. The terms "application" and "program" refer to one or more computer programs, software components, instruction sets, processes, functions, objects, classes, instances, related data or a portion thereof suitable for implementation with suitable computer-readable program code. The phrase "computer-readable program code" includes any type of computer code, including source code, object code and executable code. The phrase "computer-readable medium" includes any type of medium that can be accessed by a computer, such as a read-only memory (ROM), a random access memory (RAM), a hard drive, a compact disk (CD), a digital video disk (DVD) or any other type of memory. "Non-transitory" computer-readable media excludes wired, wireless, optical or other communication links that transmit transient electrical or other signals. Non-transitory computer-readable media include media that can store data permanently, as well as media that can store data and then rewrite data, such as rewritable optical disks or erasable memory devices.

[0017] Definitions for certain other words and phrases are provided throughout this patent document. Those of ordinary skill in the art should understand that in many, if not most instances, such definitions apply to prior, as well as future uses of such defined words and phrases.

[0018] Advantageous Effects of the Invention

[0019] According to various embodiments of the present disclosure, the quality of service assurance of a WebRTC session in a wireless communication system may be effectively enhanced. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] For a more complete understanding of the present disclosure and its advantages, reference is now made to the following description taken in conjunction with the accompanying drawings, in which like reference numerals represent like parts: Figure 1 An exemplary communication system according to an embodiment of the present disclosure is presented; Figure 2 An exemplary electronic device according to an embodiment of the present disclosure is shown; Figure 3 An exemplary electronic device according to an embodiment of the present disclosure is shown; Figure 4 An exemplary architecture of a media stream according to the present disclosure is presented; Figure 5 An exemplary WebRTC between two clients according to the present disclosure is shown; Figure 6 An exemplary WebRTC session in a network slice according to the present disclosure is shown; Figure 7 An exemplary WebRTC session with direct peer-to-peer media transfer according to the present disclosure is shown; Fig. 8A and Figure 8B An example of WebRTC session traffic on multiple network slices according to the present disclosure is shown; Fig. 9 Exemplary edge slicing of WebRTC according to the present disclosure is shown; Fig.10 Exemplary traffic prioritization using priority queues in accordance with the present disclosure is shown; Fig.11 Exemplary traffic prioritization using network segment delay configuration according to the present disclosure is presented; Fig.12 An exemplary method for WebRTC QoS assurance using network slicing according to the present disclosure is presented; Fig.13 An exemplary method of WebRTC QoS assurance influenced by a user equipment (UE) using network slicing according to the present disclosure is presented; Fig.14 An exemplary network slice in a remote cloud according to the present disclosure is shown; Fig.15 An exemplary network slice in an edge network according to the present disclosure is shown; Fig.16 An exemplary WebRTC service configuration according to the present disclosure is shown; Fig.17 An exemplary inter-mobile network operator (MNO) WebRTC session according to the present disclosure is shown; Fig.18 An exemplary single WebRTC signaling for multiple MNOs according to the present disclosure is shown; Fig.19 An exemplary service configuration for an inter-MNO WebRTC service according to the present disclosure is presented; Fig. 20 An exemplary QoS status notification of a WebRTC service to an application provider according to the present disclosure is shown; Fig.21 An exemplary end-to-end view of QOS according to the present disclosure is presented; Fig. 22 Exemplary QoS compensation at network segments due to QoS degradation at different network segments according to the present disclosure is presented; Fig.23 Exemplary QoS compensation at different MNO networks according to the present disclosure is shown; Fig.24 Exemplary QoS compensation methods at different MNO networks according to the present disclosure are presented; Fig.25 Exemplary QoS compensation at different MNO networks according to the present disclosure is shown; Fig.26 An exemplary method for ensuring QoS for WebRTC sessions in a 5G network according to the present disclosure is presented; Fig. 27 A block diagram of a terminal (or user equipment (UE)) according to an embodiment as disclosed herein is shown; Fig.28 A block diagram showing a base station (BS) according to embodiments as disclosed herein; and Fig.29 A block diagram of a network entity (NE) according to embodiments as disclosed herein is shown.

[0021] It may be noted that, to the extent possible, the same reference symbols have been used to represent the same elements in the figures. In addition, it will be understood by those of ordinary skill in the art that the elements in the figures are shown for simplicity and may not necessarily be drawn to scale. For example, the dimensions of some elements in the figures may be exaggerated relative to other elements to help improve understanding of aspects of the present invention. In addition, one or more elements may have been represented in the figures by conventional symbols, and the figures may only show specific details relevant to understanding embodiments of the present invention, so as not to obscure the figures from details that would be readily apparent to those of ordinary skill in the art having the benefit of the description herein. DETAILED DESCRIPTION

[0022] Real-time communication systems using WebRTC are developed as peer-to-peer media stream exchange systems, where the communicating peers use a set of WebRTC signaling servers to set up end-to-end media connections to exchange one or more media streams. Due to the capabilities of the endpoint devices and network capabilities, traditional audio and two-dimensional (2D) video traffic can be exchanged between the communicating peers. As network processing power increases, two-way conversation systems are able to run multi-party conference systems, where the media streams from each peer are mixed in the network conference media function, and the mixed media streams are then transmitted to all other users in the conversation.

[0023] Described below Figures 1 to 29 The various embodiments used to describe the principles of the present disclosure are for illustration only and should not be interpreted in any way as limiting the scope of the present disclosure. Those skilled in the art will appreciate that the principles of the present disclosure can be implemented in any type of appropriately arranged device or system.

[0024] Traditional WebRTC is a best-effort service because the communication between participating peers is carried out over the Internet and the client endpoints are mainly based on browsers. WebRTC QoS is based on local prioritization of media streams in the outbound direction, so that high-priority traffic has a better chance of being delivered than low-priority traffic. In addition, WebRTC media streams are marked with Differentiated Services Code Point (DSCP) for forwarding processing in the network. However, these QoS mechanisms are not enough because DSCP packet marking is not strictly followed in the network. In addition, local prioritization will apply to traditional media types such as audio and 2D video. For enhanced media types such as 3D capture encoding, volumetric media types, tactile media types, etc., a simple local prioritization scheme is not enough. In addition, there is no QoS guarantee mechanism for WebRTC to ensure session quality.

[0025] The present disclosure provides aspects related to ensuring the quality of WebRTC sessions when providing WebRTC in a hosted network; providing WebRTC service parameters by an external WebRTC service provider; and using network slicing to differentiate WebRTC traffic. Features described in the present disclosure include prioritizing WebRTC media streams using priority queues and network segment delay configuration in network slices; network and UE impact methods for ensuring QoS for WebRTC sessions; and using mobile operator core and edge network slices for WebRTC services

[0026] WebRTC allows real-time communication between participating peers using the exchange of real-time media streams between their WebRTC endpoints. Different types of media streams (e.g., voice, video, data) can be exchanged between participating peers to achieve real-time communication. With the advancement of WebRTC-related technologies, multi-party communication has become possible, where the media stream from one participant is available to every other participant in the communication. Media gateway devices are provided to mix the media stream traffic of multiple users before forwarding it to the participants. Specifications are developed to provide a certain level of security, quality of service (QoS), and quality of experience (QoE) to end users participating in WebRTC sessions.

[0027] Traditionally, WebRTC services are deployed as Internet applications to enable communication between two or more end users. With the advent of newer 5G-related technologies, attempts are being made to provide this service as a subscription-based service to MNO users. For MNO users, quality is critical, so WebRTC services must have certain quality assurance. WebRTC relies on the prioritization of media streams defined by endpoints to affect the outgoing bitrate / throughput of media streams, as well as DSCP packet marking for network-level QoS. However, in order to provide WebRTC services in MNO networks, certain QoS mechanisms and management methods must be defined so that WebRTC sessions in MNO networks do not suffer from QoS issues.

[0028] The present disclosure describes aspects related to: QoS management aspects of WebRTC sessions when providing for 5G users; QoS aspects of inter-MNO WebRTC sessions spanning more than one operator network; and adjusting QoS parameters / schemes to optimize end-to-end QoS for WebRTC sessions. Described in the present disclosure are methods for monitoring QoS and reconfiguring parameters of different QoS schemes and compensating QoS scheme parameters using current QoS state information.

[0029] The use of computing technology in media processing is expanding greatly, primarily due to the availability, convenience, and computing power of computing devices. Portable electronic devices, such as laptop computers and mobile smartphones, are becoming more popular as the devices become more compact, while the processing power and resources contained in a given device are increasing. Even with the increase in processing power, portable electronic devices often have difficulty providing the processing power to handle new services and applications, which generally require more resources contained in the portable electronic device. Improved methods and apparatus are needed for configuring and deploying media processing in a network.

[0030] Cloud media processing is gaining acceptance, where media processing workloads are placed in a network (e.g., the cloud) to take advantage of the benefits provided by the cloud: such as (theoretically) unlimited computing power, automatic scaling based on need, and on-demand processing. End-user clients can request network media processing providers to provision and configure media processing capabilities as needed.

[0031] The various embodiments used to describe the principles of the present disclosure in the accompanying drawings discussed below and this patent document are for illustration only and should not be construed in any way to limit the scope of the present disclosure. Those skilled in the art will appreciate that the principles of the present disclosure can be implemented in any suitably arranged system or device.

[0032] the following Figures 1 to 3 Various embodiments are described that are implemented in a wireless communication system and utilizing Orthogonal Frequency Division Multiplexing (OFDM) or Orthogonal Frequency Division Multiple Access (OFDMA) communication techniques. Figures 1 to 3 The description is not intended to imply physical or architectural limitations to the manner in which different embodiments may be implemented. Different embodiments of the present disclosure may be implemented in any suitably arranged communications system.

[0033] Figure 1 An exemplary communication system 100 is shown in accordance with an embodiment of the present disclosure. Figure 1 The embodiment of the communication system 100 shown is for illustration only. Other embodiments of the communication system 100 may be used without departing from the scope of the present disclosure.

[0034] like Figure 1 As shown, the communication system 100 includes a network 102 that facilitates communication between various components in the communication system 100. For example, the network 102 can pass IP packets, frame relay frames, asynchronous transfer mode (ATM) cells, or other information between network addresses. The network 102 includes all or a portion of one or more local area networks (LANs), metropolitan area networks (MANs), wide area networks (WANs), a global network (such as the Internet), or one or more other communication systems at one or more locations.

[0035] In this example, the network 102 facilitates communication between the server 104 and various client devices 106 to 116. The client devices 106 to 116 may be, for example, smartphones, tablets, laptops, personal computers, wearable devices, HMDs, etc. The server 104 may represent one or more servers. Each server 104 includes any suitable computing or processing device that can provide computing services to one or more client devices (e.g., client devices 106 to 116). Each server 104 may, for example, include one or more processing devices, one or more memories storing instructions and data, and one or more network interfaces that facilitate communication over the network 102. In some embodiments, each server 104 may include an encoder. In some embodiments, the server 104 may provide QoS guarantees for WebRTC sessions in a 5G network to the client devices 106 to 116.

[0036] Each client device 106-116 represents any suitable computing or processing device that interacts with at least one server (e.g., server 104) or other computing device on network 102. Client devices 106-116 include desktop computers 106, mobile phones or mobile devices 108 (e.g., smartphones), PDAs 110, laptops 112, tablets 114, and HMDs 116. However, any other or additional client devices may be used in communication system 100. Smartphones represent one type of mobile device 108 that are handheld devices with a mobile operating system and integrated mobile broadband cellular network connectivity for voice, short message service (SMS), and Internet data communications.

[0037] In this example, some of the client devices 108 to 116 communicate indirectly with the network 102. For example, the mobile device 108 and the PDA 110 communicate via one or more base stations 118, such as cellular base stations 120 or eNodeBs (eNBs). In addition, the laptop 112, the tablet 114, and the HMD 116 communicate via one or more wireless access points 120, such as IEEE 802.11 wireless access points. It should be noted that these are for illustration only, and each client device 106 to 116 can communicate directly with the network 102, or indirectly with the network 102 via any suitable intermediate device or network.

[0038] In some embodiments, any client device 106 to 114 can utilize or perform a QoS assurance process for a WebRTC session in a 5G network. Similarly, in various embodiments, the server 104 can utilize or perform a QoS assurance process for a WebRTC session in a 5G network.

[0039] although Figure 1 An example of a communication system 100 is shown, but may be used for Figure 1 Various modifications may be made. For example, communication system 100 may include any number of each component in any suitable arrangement. In general, computing and communication systems have a wide variety of configurations, and Figure 1 The scope of the present disclosure is not limited to any particular configuration. Figure 1 One operating environment is shown in which the various features disclosed in this patent document may be used, but these features may be used in any other suitable system.

[0040] Figure 2 and Figure 3 An exemplary electronic device according to an embodiment of the present disclosure is shown. Specifically, Figure 2 An exemplary server 200 is shown, and the server 200 may represent Figure 1 Server 200 may represent one or more encoders, decoders, local servers, remote servers, cluster computers, and components that act as a single seamless resource pool, cloud-based servers, etc. Server 200 may be composed of Figure 1 One or more client devices 106 to 116 or another server for access.

[0041] like Figure 2 As shown, server 200 includes a bus system 205 that supports communications between at least one processing device (eg, processor 210 ), at least one storage device 215 , at least one communication interface 220 , and at least one input / output (I / O) unit 225 .

[0042] The processor 210 executes instructions that may be stored in the memory 230. The processor 210 may include any suitable number and type of processors or other devices in any suitable arrangement. Exemplary types of processors 210 include microprocessors, microcontrollers, digital signal processors, field programmable gate arrays, application-specific integrated circuits, and discrete circuits. In some embodiments, the processor 210 may provide QoS assurance for WebRTC sessions in a 5G network.

[0043] Memory 230 and permanent storage 235 are examples of storage devices 215, which represent any structure capable of storing information (e.g., data, program code, or other suitable information on a temporary or permanent basis) and facilitating retrieval of the information. Memory 230 may represent random access memory or any other suitable volatile or nonvolatile storage device. Permanent storage 235 may contain one or more components or devices that support longer-term data storage, such as read-only memory, a hard drive, flash memory, or an optical disk.

[0044] Communication interface 220 supports communication with other systems or devices. For example, communication interface 220 may include interfaces that facilitate communication via Figure 1 The communication interface 220 may include a network interface card or wireless transceiver for communicating with the network 102. The communication interface 220 may support communication over any suitable physical or wireless communication link. For example, the communication interface 220 may transmit information related to QoS assurance of a WebRTC session in a 5G network to another device: for example, one of the client devices 106 to 116.

[0045] The I / O unit 225 allows for the input and output of data. For example, the I / O unit 225 can provide a connection for user input via a keyboard, mouse, keypad, touch screen, or other suitable input device. The I / O unit 225 can also send output to a display, printer, or other suitable output device. However, please note that the I / O unit 225 can be omitted when, for example, an I / O interaction with the server 200 is performed via a network connection.

[0046] It should be noted that although Figure 2 Described as indicating Figure 1 104, but the same or similar structure may be used in one or more of the various client devices 106 to 116. For example, a desktop computer 106 or a laptop computer 112 may have a Figure 2 The same or similar structure as shown.

[0047] Figure 3 An exemplary electronic device 300 is shown and may represent Figure 1 The electronic device 300 may be a mobile communication device, such as a mobile station, a subscriber station, a wireless terminal, a desktop computer (similar to a Figure 1 desktop computer 106), portable electronic devices (similar to Figure 1 In some embodiments, Figure 1 One or more client devices 106 to 116 may include the same or similar configuration as the electronic device 300. In some embodiments, the electronic device 300 is an encoder, a decoder, or both. For example, the electronic device 300 may be used for data transmission, image or video compression, image or video decompression, encoding, decoding, and media rendering applications.

[0048] The RF transceiver 310 receives incoming RF signals transmitted from an access point (e.g., a base station, a WIFI router, or a Bluetooth device) or other devices of the network 102 (e.g., WI-FI, Bluetooth, cellular, 5G, LTE, LTE-A, WiMAX, or any other type of wireless network) from the antenna 305. The RF transceiver 310 down-converts the incoming RF signals to generate an intermediate frequency or baseband signal. The intermediate frequency or baseband signal is sent to the RX processing circuit, which generates a processed baseband signal by filtering, decoding, and / or digitizing the baseband or intermediate frequency signal. The RX processing circuit transmits the processed baseband signal to the speaker 330 (e.g., for voice data) or the processor 340 for further processing (e.g., for web browsing data).

[0049] The TX processing circuit receives analog or digital voice data from microphone 320 or other outgoing baseband data from processor 340. The outgoing baseband data may include web data, email, or interactive video game data. The TX processing circuit encodes, multiplexes, and / or digitizes the outgoing baseband data to generate a processed baseband or intermediate frequency signal. The RF transceiver 310 receives the outgoing processed baseband or intermediate frequency signal from the TX processing circuit and up-converts the baseband or intermediate frequency signal to an RF signal transmitted via antenna 305.

[0050] The processor 340 may include one or more processors or other processing devices. The processor 340 may execute instructions stored in a memory 360 such as an OS 361 to control the overall operation of the electronic device 300. For example, according to well-known principles, the processor 340 may control the reception of forward channel signals and the transmission of reverse channel signals through the RF transceiver 310. The processor 340 may include any suitable number and type of processors or other devices in any suitable arrangement. For example, in some embodiments, the processor 340 includes at least one microprocessor or microcontroller. Exemplary types of processors 340 include microprocessors, microcontrollers, digital signal processors, field programmable gate arrays, application-specific integrated circuits, and discrete circuits. In some embodiments, the processor 340 may provide QoS assurance for WebRTC sessions in a 5G network.

[0051] The processor 340 is also capable of executing other processes and programs residing in the memory 360, such as operations of receiving and storing data. The processor 340 can move data into or out of the memory 360 as needed for the execution process. In some embodiments, the processor 340 is configured to execute one or more applications 362 based on the OS 361 or in response to a signal received from an external source or operator. For example, the application 362 may include an encoder, a decoder, a VR or AR application, a camera application (for still images and videos), a video phone call application, an email client, a social media client, an SMS messaging client, a virtual assistant, etc. In some embodiments, the processor 340 is configured to receive and transmit media content in multiple media streams through separate network slices. The processor 340 can provide QoS assurance for WebRTC sessions in a 5G network.

[0052] Processor 340 is also coupled to I / O interface 345, which provides electronic device 300 with the ability to connect to other devices, such as client devices 106-114. I / O interface 345 is the communication path between these accessories and processor 340.

[0053] The processor 340 is also coupled to the input 350 and the display 355. The operator of the electronic device 300 can use the input 350 to enter data or input into the electronic device 300. The input 350 can be a keyboard, a touch screen, a mouse, a trackball, a voice input, or other devices that can act as a user interface to allow the user to interact with the electronic device 300. For example, the input 350 may include a voice recognition process, thereby allowing the user to enter a voice command. In another example, the input 350 may include a touch panel, a (digital) pen sensor, a key, or an ultrasonic input device. The touch panel may recognize, for example, a touch input in at least one scheme such as a capacitive scheme, a pressure-sensitive scheme, an infrared scheme, or an ultrasonic scheme. The input 350 may be associated with a sensor 365 and / or a camera by providing additional input to the processor 340. In some embodiments, the sensor 365 includes one or more inertial measurement units (IMUs) (such as accelerometers, gyroscopes, and magnetometers), motion sensors, optical sensors, cameras, pressure sensors, heart rate sensors, altimeters, etc. The input 350 may also include a control circuit. In a capacitive approach, input 350 may recognize touch or proximity.

[0054] Display 355 may be a liquid crystal display (LCD), a light emitting diode (LED) display, an organic LED (OLED), an active matrix OLED (AMOLED), or other display capable of rendering text and / or graphics, such as from websites, videos, games, and images. The size of display 355 may be adjusted to fit the HMD. Display 355 may be a single display screen or multiple display screens capable of creating a stereoscopic display. In some embodiments, display 355 is a head-up display (HUD). Display 355 may display 3D objects such as 3D point clouds.

[0055] Memory 360 is coupled to processor 340. A portion of memory 360 may include RAM, and another portion of memory 360 may include flash memory or other ROM. Memory 360 may include a permanent storage device (not shown) representing any structure capable of storing information (e.g., data, program code, and / or other suitable information) and facilitating retrieval of information. Memory 360 may include one or more components or devices that support longer-term data storage, such as a read-only memory, a hard drive, flash memory, or an optical disk. Memory 360 may also include media content. Media content may include various types of media such as images, videos, three-dimensional content, VR content, AR content, 3D point clouds, and the like.

[0056] The electronic device 300 also includes one or more sensors 365, which can measure physical quantities or detect the activation state of the electronic device 300, and convert the measured or detected information into electrical signals. For example, the sensor 365 may include one or more buttons for touch input, a camera, a posture sensor, an IMU sensor (such as a gyroscope or a gyroscope sensor and an accelerometer), an eye tracking sensor, an air pressure sensor, a magnetic sensor or a magnetometer, a grip sensor, a proximity sensor, a color sensor, a biophysical sensor, a temperature / humidity sensor, an illumination sensor, an ultraviolet (UV) sensor, an electromyography (EMG) sensor, an electroencephalography (EEG) sensor, an electrocardiography (ECG) sensor, an IR sensor, an ultrasonic sensor, an iris sensor, a fingerprint sensor, a color sensor (such as a red, green, and blue (RGB) sensor), etc. The sensor 365 may also include a control circuit for controlling any one of the sensors included therein.

[0057] although Figure 2 and Figure 3 An example of an electronic device is shown, but Figure 2 and Figure 3 Make various changes. For example, Figure 2 and Figure 3The various components in the embodiment may be combined, further subdivided, or omitted, and additional components may be added as required. As a specific example, processor 340 may be divided into multiple processors, such as one or more central processing units (CPUs) and one or more graphics processing units (GPUs). In addition, as with computing and communications, electronic devices and servers may have a variety of configurations, and Figure 2 and Figure 3 The present disclosure is not limited to any particular electronic device or server.

[0058] Figure 4 An exemplary architecture 400 of a media flow according to the present disclosure is shown. Figure 4 The embodiment for media streaming architecture 400 shown in FIG. 4 is for illustration only. Figure 4 The scope of the present disclosure is not limited to any particular implementation of an electronic device.

[0059] 5G media streaming is enabled by setting up an application function (AF) in the core data network (DN) 404. The signaling application function server 418 performs the signaling function and the media application function server 420 performs the media function. Depending on the application requirements, there can be multiple instances of these application functions in the core data network 404. Different components of the UE 402 connect to these application functions to exchange signaling and media data to receive the 4G media streaming service provided by the mobile operator. The signaling application function server 418 can be composed of Figure 2 The server 200 shown in FIG. 4 is represented by the server 200, and the UE 403 can be represented by Figure 3 The electronic device shown in is represented.

[0060] like Figure 4 As shown, 3GPP TS 26.512 specifies a reference to a media streaming architecture 400 for 4G Media Streaming (5GMS). 3GPP SA Working Group 4 (SA4) is standardizing media services for deployment in 4G networks. Different system components of the 4G media streaming architecture 400 may include a UE 402 and a data network 404. The UE 402 may include an awareness application 410 and an edge enabler client 412 (5GMSd client). The data network 404 may include an application provider 414 (5GMSd application provider), a signaling application function server 418 (5GMSd AF), and a processing media application function server (5GMSd) 420. The 4GMSd client 412 may include a media session processor 422 and a media player 424. The 4GMSd client 412 may correspond to Figure 4 The edge enabler client 412 shown in .

[0061] The aware application 410 is stored in the UE 402. The aware application 410 receives application service information from the application provider. The application service information is then used to retrieve information and data related to the application from the data network.

[0062] The signaling application function server 418 is a function in the data network 404 that performs signaling functions for application services. The signaling application function server 418 provides various control functions to the media session processor and / or 4GMSd application provider on the UE 402. The signaling application function server 418 can relay or initiate requests for different policy control functions (PCF) 406 processing or interact with other network functions.

[0063] The media application function server 420 is an application server that hosts media functions. The media application function server 420 is dedicated to media streaming. The media application function server 420 can deliver volumetric media streaming to the UE 402.

[0064] The media session processor 422 is a component of the UE 402 that enables communication with the signaling application function server 418 in the data network 404. The communication with the signaling application function server 418 is used to establish a relevant media channel between the UE 402 and the data network 404.

[0065] The media player 424 is a component of the UE 402. The media player 424 may receive media data from a media application function in the data network 404. The media player 424 may provide data to the 4GMSd aware application 410.

[0066] although Figure 4 The media stream architecture 400 is shown, but Figure 4 Various changes may be made. For example, the media stream architecture 400 and its various components may be varied as needed or desired. In addition, the number and placement of the various components of the media stream architecture 400 may be varied as needed or desired. In addition, the media stream architecture 400 may be used for any other suitable media stream processing and is not limited to the specific processing described above.

[0067] Figure 5 An exemplary WebRTC 500 between two clients according to the present disclosure is shown. Figure 5 The illustrated embodiment of WebRTC 500 is for illustration only. Figure 5 The scope of the present disclosure is not limited to any particular implementation of a media streaming system.

[0068] like Figure 5 As shown, WebRTC 500 is a real-time communication protocol between two peers (usually using Figure 6604). WebRTC 500 provides support for direct interactive rich communication between two peer endpoints. Many Internet Engineering Task Force (IETF) standard documents discuss the WebRTC protocol (RFC 8825), WebRTC transport (RFC8834, 8835, etc.). Simple two-way communication between two peers using WebRTC is described in Request for Comments (RFC) 8825 and is described in Figure 5 shown.

[0069] like Figure 5 As shown, one or more signaling servers 502 help establish a WebRTC session between two browser clients. During the session setup phase, the two clients agree on media and data channel descriptions so that media payloads and data can be transmitted directly between the two peers. The commonly used protocol for agreeing on session descriptions is SDP. The RTP and RTCP protocols are used to transmit peer media and control data. The WebRTC Data Channel Establishment Protocol (RFC 8832) is used to establish a communication channel to transmit data between two peers. In addition to signaling and media protocols, during the session setup phase, the following protocols can be used to discover and enable communication between peers behind NAT: Network Address Translation (NAT) Session Traversal Utilities (STUN) as specified in RFC 5389 and 8489, Traversal through NAT Relays (TURN) as specified in RFC 5766 and 6062, and Interactive Connectivity Establishment (ICE) as specified in RFC 5245 and 8445.

[0070] WebRTC 500 may use Differentiated Services Code Point (DSCP) packet marking (RFC 8837) for QoS. This standard recommends a set of DSCP values ​​for WebRTC applications. In addition, possible configurations for WebRTC transport are as follows: as described in RFC 8835, which includes each media stream being carried in its own 5-tuple, media streams being grouped into 5-tuples by media type (such as carrying all audio in one 5-tuple); and all media being sent via a single 5-tuple, which may or may not be differentiated into 6-tuples based on DSCP. In each of the above configurations, the data channel may be carried in its own 5-tuple or multiplexed with one of the media streams.

[0071] Since WebRTC 500 was primarily developed to enable real-time communication between peers over the Internet, the QoS possibilities of WebRTC 500 are limited to the QoS that is possible on the Internet, namely the DSCP mechanism. However, WebRTC 500 can be used for 5G services for registered 5G mobile users. In 3GPP, WebRTC technology is being mapped to the same services on 5G networks. However, 3GPP specifies QoS for 5G traffic using the 5QI QoS model specified in 3GPP TS 23.501. In this case, if such services can be deployed and delivered over 5G networks, it is easy to try to map the service classes and DSCP values ​​of WebRTC applications to possible 5QI values ​​in 5G.

[0072] 3GPP SA4 is studying the deployment architecture of WebRTC services in 5G networks and is specified in Technical Report (TR) 26930 or TS 26.113 or TS 26.506. A set of collaboration scenarios for WebRTC in 5G networks is being studied as shown below.

[0073] In the first scenario of over the top (OTT) WebRTC, WebRTC service components (such as signaling server and STUN / TURN / ICE / MCU functions) are deployed in the external service provider domain. WebRTC services are provided as OTT services to operator users.

[0074] In the second scenario where the MNO provides trusted WebRTC functions, WebRTC auxiliary functions such as STUN / TURN / MCU are provided by the MNO, but the signaling server is deployed in the external service provider network.

[0075] In the third scenario of MNO-facilitated WebRTC services, all WebRTC functions including signaling can be provided by the MNO.

[0076] For interoperable WebRTC services, all WebRTC functions can be provided by the MNO and the WebRTC services can interoperate across different operators.

[0077] Traditional WebRTC mainly supports two QoS mechanisms, including local prioritization of media streams and network QoS using DSCP packet marking. For local prioritization of media streams, the WebRTC endpoint in the UE determines the relative priority of different media streams in the WebRTC service. This is applicable when there are multiple flows as part of a WebRTC session and the scheduler at the endpoint needs to give priority to one media stream. Based on the priority defined by the endpoint, higher bandwidth and throughput are allocated to the media stream. This helps ensure that higher priority media streams reach the desired destination at the expense of lower priority media streams in the event that the network cannot provide enough bandwidth for all media streams.

[0078] For network QoS using DSCP packet marking, outgoing packets of different media streams from WebRTC endpoints are marked with DSCP values, indicating different packet treatment at network routing and switching equipment. It is not mandatory for network switches and routers to strictly follow DSCP packet marking, but it is recommended by the WebRTC specification.

[0079] Although the above QoS mechanisms are QoS mechanisms defined by WebRTC, when providing WebRTC services to mobile operator users, certain types of QoS features are necessary for running WebRTC services in the operator network so that the end users of the WebRTC service have an adequate service experience. Such QoS requirements can be the minimum amount of bandwidth allocated to a WebRTC session; the minimum throughput of a WebRTC session, the maximum packet loss rate of a WebRTC session, and the maximum end-to-end delay of a WebRTC session. There are also many end-to-end QoS schemes for managing the QoS of IP traffic in the network. The first QoS scheme can be classification, where such a scheme defines how to classify packets of IP traffic (e.g., voice packets, data packets, etc.) so that differentiated treatment can be provided based on the classification. For example, the second QoS scheme can be regulation, where such a scheme defines how to control the bandwidth of IP traffic at the inbound port. The third QoS scheme can be marking, where such a scheme defines how to mark packets of IP traffic with certain QoS values ​​so that network devices can provide differentiated treatment for such packets, thereby providing differentiated treatment for associated IP traffic. The fourth QoS scheme can be propagation, where such a scheme defines how to convert QoS settings at different locations for end-to-end QoS. For example, how the network stack in the endpoint translates application QoS settings into network QoS settings, maps network QoS settings to frame-level QoS settings (e.g., IP->Ethernet), how QoS settings are mapped if encapsulation is used (e.g., GRE tunnel, etc.). A fifth QoS scheme may be metering, where such a scheme defines how bandwidth is implemented at an outbound location (e.g., an egress port). A sixth QoS scheme may be queuing, where such a scheme defines how queues are managed (e.g., provisioned, measured, etc.) at different locations along the end-to-end network path.

[0080] although Figure 5 An exemplary WebRTC 500 between two clients is shown, but Figure 5 Various changes may be made. For example, WebRTC 500 and its various components may be varied as needed or desired. In addition, the number and placement of the various components of WebRTC 500 may be varied as needed or desired. In addition, WebRTC 500 may be used for any other suitable media stream processing and is not limited to the specific processing described above.

[0081] Figure 6 An exemplary WebRTC session 600 in a network slice 602 according to the present disclosure is shown. Figure 6 The embodiment of the WebRTC session 600 shown in FIG. 6 is for illustration only. Figure 6 The scope of the present disclosure is not limited to any particular implementation of a media streaming system.

[0082] like Figure 6 As shown, network slicing in 5G helps to achieve service differentiation in terms of network configuration and QoS. In 5G, network slice 602 can be used to provide differentiated QoS for component service flows. WebRTC session 600 can be transmitted through dedicated / separate network slice 602.

[0083] Figure 6 A simple WebRTC session 600 using network slicing 602, referred to as "WebRTC slicing," is shown. The figure shows an exemplary session between two clients 604 located behind the same base station (gNB) 606. However, these sessions can be generalized to clients 604 located behind different gNBs 606.

[0084] The WebRTC media and data channel functionality 608 may process one or more media types (e.g., audio, video, 3D representations such as point clouds, 3D meshes) and WebRTC data channel messages. The WebRTC signaling functionality 610 may be located in the application domain 612 outside of the MNO domain 614. However, the mobile network operator (MNO) may also provide the WebRTC signaling functionality 610 inside the operator network, in which case the signaling messages 616 do not enter the application domain 612.

[0085] Figure 6 Also used as an example of media processing in a network, media data from a client 604 flows from the MNO domain 614 into the application domain, optionally processed or transformed (e.g., WebRTC conferencing), and the resulting media traffic 618 is then sent to the client 604. However, the MNO 620 may also provide WebRTC media functionality 608 inside the operator network, in which case the media traffic 618 does not enter the application domain 612, but is instead processed in the MNO domain 614.

[0086] Figure 6 It is also used as an example of media data processing before the generated media data is sent to the communication client 604. However, there may be no need for media processing (e.g., a two-way WebRTC session), and the media data flows directly between the two clients 604, such as Figure 7 shown.

[0087] although Figure 6 An exemplary WebRTC session 600 in a network slice 602 is shown, but the Figure 6Various changes may be made. For example, the number and placement of the various components of the media WebRTC session 600 may vary as needed or desired. In addition, the WebRTC session 600 may be used for any other suitable media stream processing and is not limited to the specific processing described above.

[0088] Figure 7 An exemplary WebRTC session 700 with direct peer-to-peer media transfer according to the present disclosure is shown. Figure 7 The embodiment of the WebRTC session 700 shown in FIG. 7 is for illustration only. Figure 7 The scope of the present disclosure is not limited to any particular implementation of a media streaming system.

[0089] like Figure 7 As shown, a WebRTC session 700 may be provided to a user of an MNO network 620. For the WebRTC session 700 to be provided to the MNO user, an application function (AF) within the MNO network may configure WebRTC service requirements, thereby enabling deployment of the WebRTC service on the MNO network 620. As part of the service requirements, the expected QoS of the WebRTC session 700 may be specified to the AF. Based on the QoS requirements, the AF may configure the necessary slice resources (e.g., with any necessary signaling and media resources), and the WebRTC service 700 begins running for use by the WebRTC client 604 in the MNO domain 614.

[0090] although Figure 7 An exemplary WebRTC session 700 with direct peer-to-peer media transfer is shown, but Figure 7 Various changes may be made. For example, the WebRTC session 700 and its various components may vary as needed or desired. In addition, the number and placement of the various components of the WebRTC session 700 may vary as needed or desired. In addition, the WebRTC session 700 may be used for any other suitable media stream processing and is not limited to the specific processing described above.

[0091] Fig. 8A and 8B Examples of WebRTC session traffic 800 and 801 over multiple network slices according to the present disclosure are shown. Fig. 8A and 8B The embodiments of WebRTC session flows 800 and 801 shown in FIG. 8 are for illustration only. Fig. 8A and Figure 8B The scope of the present disclosure is not limited to any particular implementation of a media streaming system.

[0092] Although the method for using one network slice 602 to transmit all WebRTC traffic is previously described, Fig. 8Aand Figure 8B A method for providing multiple network slices for WebRTC sessions 800 and 801 is provided.

[0093] like Fig. 8A As shown, media traffic 618 including media data 818 and data channel traffic 819 is transmitted through a single network slice 602b, and all signaling messages 616 are transmitted through a separate network slice 602a. This situation is possible if the single network slice 602 cannot accommodate all signaling messages 616, media data 818, and data channel traffic 819. This situation may occur when the signaling function 610 and the media function 608 are developed and deployed by different vendors and they cannot interoperate and may be for QoS reasons.

[0094] like Figure 8B As shown, WebRTC traffic can be further partitioned when signaling messages 616, media data 818, and data channel traffic 819 are transmitted through separate network slices 602a, 602b, and 602c.

[0095] In order to provide WebRTC services through multiple network slices 602, an application service provider (e.g., a WebRTC service provider) can configure a network application function so that multiple network slices 602 are set up to provide services for WebRTC sessions. The operation mode (whether to use WebRTC session traffic 800 or WebRTC session traffic 801) is also specified by the service provider. When the application function within the operator network receives information from the application service provider, the operator can provide the required number of network slices 602 and make the network slices 602 available for transmitting WebRTC traffic.

[0096] Similar to the case of a single network slice 602, even in the case of multiple network slices 602, the service provider can provide service requirements (including QoS expectations) to the application function, and the application function can convert the service requirements into slice deployment so that the service requirements can be met.

[0097] although Fig. 8A and Figure 8B The example of WebRTC session traffic 800 and 801 on multiple network slices is shown, but Fig. 8A and Figure 8B Various changes may be made. For example, the number and placement of the various components of WebRTC session flows 800 and 801 may vary as needed or desired. In addition, WebRTC session flows 800 and 801 may be used for any other suitable media stream processing and are not limited to the specific processing described above.

[0098] Fig. 9An exemplary edge slice 900 for WebRTC according to the present disclosure is shown. Fig. 9 The embodiment of edge slice 900 shown in FIG. 9 is for illustration only. Fig. 9 The scope of the present disclosure is not limited to any particular implementation of a media streaming system.

[0099] like Fig. 9 As shown, the edge network 922 is sliced ​​in a way that the QoS of the media and data channel traffic is differentiated. With this option, a separate network slice 602 in the core network can be provided for WebRTC traffic, or a default network slice 602 can be used in the core network. However, in the edge network 922, different slices 602a and 602b can be provided to support differentiated QoS for WebRTC traffic.

[0100] like Fig. 9 As shown, the edge network 922 can be sliced ​​to provide differentiated QoS to different types of WebRTC traffic. With this deployment option, an edge user plane function (UPF) 924 can be provided near the gNB 606 to help route WebRTC traffic to the edge network 922. The QoS of WebRTC traffic can be managed similarly to the case described previously in this disclosure.

[0101] Fig. 9 The WebRTC media and data channel functions 608 are shown to handle both media data 618 and data channel traffic 819 in different edge network slices. In some embodiments, separate WebRTC media data functions and data channel functions are developed and deployed in different network slices 602, which can be independently responsible for handling media data 618 and data channel traffic 819, respectively.

[0102] although Fig. 9 An exemplary edge slice 900 for WebRTC is shown, but may be Fig. 9 Various modifications may be made. For example, the number and placement of the various components of edge slice 900 may vary as needed or desired. Furthermore, edge slice 900 may be used for any other suitable media stream processing and is not limited to the specific processing described above.

[0103] Fig.10 An exemplary traffic prioritization 1000 using a priority queue 1002 in accordance with the present disclosure is shown. Fig.10 The embodiment of traffic prioritization 1000 shown in FIG. 1 is for illustration only. Fig.10 The scope of the present disclosure is not limited to any particular implementation of a media streaming system.

[0104] like Fig.10As shown, WebRTC's QoS mechanism addresses two areas of concern, local prioritization and network handling of WebRTC traffic using DSCP marking. Local prioritization refers to prioritizing the outgoing bandwidth of endpoints with high-priority traffic over endpoints with low-priority traffic. Prioritization can be achieved by the application signaling to lower layers about the priority of each media stream. WebRTC endpoints can transmit data in such a way that each stream at each level of priority can use twice the available bandwidth compared to streams with lower priorities.

[0105] Network treatment of WebRTC traffic using DSCP marking involves WebRTC endpoints marking outgoing packets with DSCP markings, as described in RFC 8837, and network nodes can allow differential treatment of packets / streams with different DSCP markings. However, such differentiated treatment is practical for WebRTC traffic with two-dimensional video data and simple audio data. For newer media types, such as 3D representation data, volumetric data (such as point clouds and light fields, etc.), the prioritization scheme defined by WebRTC may not be feasible. In addition, different media types may have different tolerances for stream prioritization. For example, for animations generated based on user movement, the animation to be sent may have a different priority compared to a point cloud media type.

[0106] One way to solve the above problem is to define relative priorities between multiple possible media types. However, due to the variety of media types, WebRTC client developers can generate media streams with different characteristics by leveraging different UE capabilities. Therefore, relying solely on endpoint-level prioritization schemes may not be sufficient.

[0107] To facilitate traffic prioritization for WebRTC, traffic prioritization 1000 using priority queues 1002 and configuration using network segments (e.g., Fig.111002). In the traffic prioritization 1000 using priority queues 1002, one or more network slices 602 may be set up to receive WebRTC media and data channel traffic from WebRTC clients 604. Each slice 602 may provide one or more priority queues 1002. Each priority queue 1002 may have a configuration with respect to priorities for retention and forwarding behavior, or each priority queue 1002 may have a specific retention time (delay) and forwarding logic defined. For example, for traffic with a lower priority, it may be sent through a priority queue 1002 with a lower priority, which may have the highest retention amount (delay time) before the stream or data packet of the media stream is forwarded upstream.

[0108] The network function in the slice may implement a priority queue 1002. The network function may be configured directly by a session-level application function or indirectly using other control functions such as PCF, session management function (SMF), etc.

[0109] although Fig.10 An exemplary traffic prioritization 1000 using priority queues is shown, but Fig.10 Various modifications may be made. For example, the number and placement of the various components of traffic prioritization 1000 may vary as needed or desired. Furthermore, traffic prioritization 1000 may be used for any other suitable media stream processing and is not limited to the specific processing described above.

[0110] Fig.11 An exemplary traffic prioritization 1100 using network segment delay configuration according to the present disclosure is shown. Fig.11 The embodiment of traffic prioritization 1100 shown in FIG. 1 is for illustration only. Fig.11 The scope of the present disclosure is not limited to any particular implementation of a media streaming system.

[0111] like Fig.11 As shown, in the traffic prioritization 1100 configured using the network segment 1102, since the network service is provided within the network slice 602, the network service can be composed of multiple forwarding paths (network segments). Each network segment 1102 can be configured with a network behavior configuration, such as a delay configuration, a bandwidth configuration, a throughput configuration, etc.

[0112] To facilitate traffic prioritization 1100, lower priority media streams may be forwarded through network segments with higher latency 1102 than higher priority media streams. Higher priority media streams will have better prioritization than lower priority media streams.

[0113] like Fig.11 As shown, network segments ABD, ACD, and AD can be configured with different delay configurations. For example, the delay configuration of ABD can have a total delay including the delay configuration of segment AB and the delay configuration of segment BD. Similarly, the delay configuration of ACD can have a total delay including the delay configuration of segment AC and the delay configuration of segment CD. Based on the delay configurations of AB, AC, BD, and CD by the service provider, all end-to-end delay configurations can be calculated, and forwarding behavior can be affected to provide traffic prioritization. Nodes A, B, C, and D can be NFs, AFs, or passive data plane devices in the network slice 602.

[0114] Even if different media streams are bundled in the same 5-tuple, the above two priority sorting mechanisms can still work. For this case, a media stream separator must be provided in the network slice 602, which can separate different media streams and use priority queues or network segments with different configurations to send different media streams.

[0115] The above method is also applicable to more than one network slice 602. One of the two prioritization mechanisms described above for using network slices can be provided in the slices used for WebRTC sessions, which is based on the provision of the service provider or network operator.

[0116] although Fig.11 An exemplary traffic prioritization 1100 using a network segment delay configuration is shown, but may be used for Fig.11 Various modifications may be made. For example, the number and placement of the various components of traffic prioritization 1100 may vary as needed or desired. Furthermore, traffic prioritization 1100 may be used for any other suitable media stream processing and is not limited to the specific processing described above.

[0117] Fig.12 An exemplary method 1200 for WebRTC QoS assurance using network slicing according to the present disclosure is shown. For ease of explanation, Fig.12 The method 1200 is described as using Figure 2 and Figure 3 However, the method 1200 may be used with any other suitable system and any other suitable electronic device.

[0118] QoS for WebRTC can be based on application prioritization of local media stream traffic, i.e., at what rate each media stream packet must be sent given the requirement for the total output bandwidth. In addition, network handling of WebRTC streams can be based on DSCP configuration. WebRTC QoS is a best-effort QoS service, especially when the service is carried along with regular Internet traffic. When WebRTC can be provided as a managed service in a network operator environment, QoS for WebRTC can be provided based on the 5G QoS mechanisms defined for operator network flows. However, there is a gap between the expected QoS of a WebRTC session and the actual QoS that a WebRTC session obtains in a 5G network.

[0119] like Fig.12 As shown, network slicing can be used to provide QoS assurance for WebRTC sessions. In step 1202, the external WebRTC service provider configures the expected QoS (SLA) for the WebRTC session at the application function in the 3GPP 5G network. The expected QoS can have any parameters, including the upload (UL) and download (DL) bit rates of the WebRTC stream, the maximum UL and DL packet error rates, the maximum UL and DL traffic per UE, the maximum UL and DL bit rates per slice, the maximum delay in the UL and DL directions, the delay or delay budget, and the UL and DL throughput. This information can be communicated to the application function in the network that manages all WebRTC sessions of all endpoints or clients 604 in the network. In addition to the SLA expectations, the service provider can also configure the relative priority of the SLA parameters.

[0120] In step 1204, the electronic device 300 may set up one or more network slices to handle the WebRTC session, provide a WebRTC media function NF and a priority queue or segment configuration, and measure the performance of each SLA parameter. Based on the SLA requirements configured for the WebRTC session, the application function may cooperate with the network operator to provide one or more network slices 602. Each slice 602 may be configured with a media function (e.g., MCU, ICE function for using STUN, TURN, etc.).

[0121] Based on the expected SLA, media capabilities are configured in each network slice. The configuration may include priority queues or network segments with latency configuration and media capabilities to handle received WebRTC media streams.

[0122] For QoS assurance, the performance of the media stream in each network slice is measured per unit time, and the SLA adjustment is calculated. The electronic device 300 may determine whether the priority queue 1002 or the network segment 1102 in each slice 602 is able to keep up with the expected SLA for each parameter applied to each media stream. The electronic device 300 may calculate the current SLA performance and calculate the required SLA adjustment based on the expected SLA and the current SLA. The adjustment of the service parameters may be based on a determination that the performance of the media stream is lower than the expected SLA.

[0123] Based on the calculated SLA adjustments, the outgoing packet behavior at the client 604 may be adjusted. For example, if a +ve 20% adjustment is required to the bitrate parameter, the outgoing bitrate for each media stream at the sender client 604 will be increased proportionally across all media streams. The increase in bitrate at the sender client 604 may require provisioning additional WebRTC signaling and media functions that may be instantiated quickly. The same adjustments may be calculated for each SLA parameter.

[0124] An action list may be prepared based on all SLA parameters. The possible actions for each SLA parameter may be as shown in Table 1 below.

[0125]

[0126] The electronic device 300 may identify an SLA parameter from the list of SLA parameters in step 1206. Based on the action list, an action corresponding to the highest priority SLA parameter may be applied.

[0127] The electronic device 300 may determine in step 1208 whether the current value of the parameter is close to or meets the expected SLA value. The SLA performance may be measured after a certain time or a certain amount of time. If the QoS does not meet the expected SLA, the method proceeds to step 1206. The actions of all SLA attributes will be performed in sequence until the QoS reaches the expected SLA value. The determination of proximity may be based on: being within a predetermined range of the expected SLA value or being above or below a predetermined percentage of the expected SLA value.

[0128] The electronic device 300 may derive endpoint actions for SLA parameters and enforce endpoint actions for SLA parameters in step 1210. To facilitate adjustment at the source endpoint, the attributes of the slice 602 carrying the WebRTC media stream are adjusted with the help of the network. Table 2 below shows information from the service provider to the application function inside the operator network for providing and managing WebRTC sessions using network slices.

[0129]

[0130] The electronic device 300 may determine whether the SLA of the WebRTC session is close to the expected (step 1212). If the SLA of the WebRTC session is not within the acceptable range of the expected SLA, the electronic device may move to the SLA parameter with the next highest priority in step 1206.

[0131] although Fig.12 An exemplary method 1200 for WebRTC QoS assurance using network slicing is shown, but may be used for Fig.12 Make various changes. For example, although Fig.12 The various steps in are shown as a series of steps, but they can overlap, occur in parallel, or occur any number of times.

[0132] Fig.13 An exemplary method 1300 for UE-influenced WebRTC QoS assurance using network slicing according to the present disclosure is shown. For ease of explanation, Fig.13 The method 1300 is described as using Figure 2 and Figure 3 However, the method 1300 may be used with any other suitable system and any other suitable electronic device.

[0133] Method 1200 provides QoS assurance by the network by measuring SLA parameters and performing certain actions when the calculated SLA parameters do not meet the expected SLA parameter values. In method 1300, a process for UE-influenced QoS assurance for a WebRTC session is described.

[0134] like Fig.13 As shown, the application service provider notifies the final UE or client 604 of the expected SLA parameters and their priorities in step 1302. These parameters are Fig.12 The parameters described in step 1202 of method 1300 shown in FIG.

[0135] The electronic device 300 or UE may calculate SLA parameters at the endpoint location in step 1304. The SLA parameters may be calculated in a manner similar to the manner in which they are calculated in step 1204 by the network.

[0136] The electronic device 300 or UE may receive the next highest priority SLA parameter in step 1206. The SLA parameter may be identified in the SLA parameter list. Step 1206 is performed for the first time using the highest priority SLA parameter.

[0137] The electronic device 300 or UE may determine whether the current value of the parameter is close to the expected SLA value in step 1308. When the current value of the SLA parameter is not close to or does not match the expected SLA parameter, the endpoint extracts the SLA parameter in descending order of priority and notifies the network to update the slice 602 to meet the SLA of the parameter. This will result in a slice attribute change or slice reconfiguration.

[0138] If the WebRTC session meets the SLA, the measurement is stopped in step 1212. Otherwise, the endpoint selects the next lower priority SLA parameter to affect the slice attribute change. This continues until the complete WebRTC session meets the SLA.

[0139] When the UE notifies the network according to the above procedure, the adjustment for each SLA parameter described in step 1210 can be similarly performed according to step 1310. The electronic device 300 can determine whether the QoS of the WebRTC session is guaranteed in step 1312, similar to the operation in step 1212.

[0140] although Fig.13 An exemplary method 1300 for ensuring UE-influenced WebRTC QoS using network slicing is shown, but may be used for Fig.13 Make various changes. For example, although Fig.13 The various steps in are shown as a series of steps, but they can overlap, occur in parallel, or occur any number of times.

[0141] Fig.14 An exemplary network slice 1400 in a remote cloud according to the present disclosure is shown. Fig.15 An exemplary network slice 1500 in an edge network according to the present disclosure is shown. Fig.14 The network slice 1400 and Fig.15 The embodiment of the network slice 1500 shown in FIG. 1 is for illustration only. Fig.14 and Fig.15 The scope of the present disclosure is not limited to any particular implementation of a media streaming system.

[0142] Fig.14 and Fig.15 Network slicing only in the application domain and edge domain are described respectively. Fig.14 It shows how WebRTC traffic is processed in a remote cloud application domain that implements slicing. WebRTC traffic can be split into multiple media streams based on 5-tuple or 6-tuple information, and the resulting media streams can be processed in different slices. Optionally, the same splitting and processing can occur in the edge network, such as Fig.15 shown.

[0143] although Fig.14An exemplary network slice 1400 is shown, and Fig.15 An exemplary network slice 1500 is shown, but Fig.14 and Fig.15 Various changes may be made. For example, the number and placement of the various components of network slice 1400 and network slice 1500 may vary as needed or desired. In addition, network slice 1400 and network slice 1500 may be used for any other suitable media stream processing and are not limited to the specific processing described above.

[0144] Fig.16 An exemplary WebRTC service configuration 1600 according to the present disclosure is shown. Fig.16 The embodiment of the WebRTC service configuration 1600 shown in FIG. 1 is for illustration only. Fig.16 The scope of the present disclosure is not limited to any particular implementation of a media streaming system.

[0145] Fig.16 The WebRTC service configuration 1600 through the application provider 1626 in the MNO network 620 is shown. The application provider 1626 configures the WebRTC service at the application function (AF) 1624 in the MNO network 620. The application function (AF) 1624 can be a 5G RTC AF as specified in TS 26.506. The WebRTC service configuration information 1628 can have the following information shown in Table 3

[0146] although Fig.16 The WebRTC service configuration 1600 is shown, but Fig.16 Various changes may be made. For example, the number and placement of the various components of the WebRTC service configuration 1600 may vary as needed or desired. In addition, the WebRTC service configuration 1600 may be used for any other suitable media stream processing and is not limited to the specific processing described above.

[0147] Fig.17 An exemplary inter-mobile network operator (MNO) WebRTC session 1700 is shown in accordance with the present disclosure. Fig.17 The embodiment of the MNO WebRTC session 1700 shown in FIG. 1 is for illustration only. Fig.17 The scope of the present disclosure is not limited to any particular implementation of a media streaming system.

[0148] like Fig.17As shown, a simple WebRTC session 1732 can connect clients 604 of two different MNOs 620a and 620b. When the application provider provides WebRTC services through network operators, clients 604 belonging to different network operators can conduct WebRTC sessions 1732. A WebRTC session 1732 can be established between endpoints or clients 604 in two different MNO networks 620a and 620b. To facilitate the inter-MNO WebRTC session 1732, a Fig.18 The WebRTC signaling server and auxiliary functions shown in Table 4. The options for the WebRTC signaling server are shown in Table 4.

[0149]

[0150] although Fig.17 An exemplary MNO WebRTC session 1700 is shown, but may be Fig.17 Various changes may be made. For example, the number and placement of the various components of the MNO WebRTC session 1700 may vary as needed or desired. In addition, the MNO WebRTC session 1700 may be used for any other suitable media stream processing and is not limited to the specific processing described above.

[0151] Fig.18 Exemplary single WebRTC signaling 1800 for multiple MNOs according to the present disclosure is shown. Fig.18 The single WebRTC signaling 1800 embodiment shown in FIG. 1 is for illustration only. Fig.18 The scope of the present disclosure is not limited to any particular implementation of a media streaming system.

[0152] like Fig.18 As shown, an external WebRTC signaling server 1834 in both MNO networks 620a and 620b can provide signaling services. Auxiliary functions can be used to deploy the WebRTC signaling server 1834. The auxiliary functions can be deployed in the external application provider network or in one of the MNO networks 620a and 620b.

[0153] If the WebRTC signaling server 1834 is deployed in an external application provider network, auxiliary functions (e.g., TURN server, STUN server, MCU, etc.) can be deployed in the external application provider, or deployed in the MNO network (based on assistance from the application provider). If the WebRTC signaling server 1834 is deployed in the MNO network 620, auxiliary functions (e.g., TURN server, STUN server, MCU, etc.) are deployed inside the MNO network 620.

[0154] although Fig.18An exemplary single WebRTC signaling 1800 for multiple MNOs is shown, but may be used for Fig.18 Various changes may be made. For example, the number and placement of the various components of the single WebRTC signaling 1800 may vary as needed or desired. In addition, the single WebRTC signaling 1800 may be used for any other suitable media stream processing and is not limited to the specific processing described above.

[0155] Fig.19 An exemplary service configuration 1900 for inter-MNO WebRTC services according to the present disclosure is shown. Fig.19 The embodiment of service configuration 1900 shown in is for illustration only. Fig.19 The scope of the present disclosure is not limited to any particular implementation of a media streaming system.

[0156] like Fig.19 As shown, the service configuration 1900 for inter-MNO services can allow the WebRTC application provider 1936 to separately configure the WebRTC services in different MNO networks 620a and 620n. The service configuration information 1940 for each of the MNOs 620a and 620b is as described earlier in this disclosure. In addition, the following information is also provided to each MNO 620, which may have the following information shown in Table 5.

[0157]

[0158] The service configuration for managing QoS of a WebRTC session from the application provider at the application function also includes the following information shown in Table 6.

[0159]

[0160] The information in Table 5 and Table 6 may be configured by the application service provider 1936 at the application function 1938 for QoS management of WebRTC sessions. When the AF 1938 receives such information, the AF 1938 may configure all network devices with the given QoS scheme configuration information. For configuration of the radio access network (RAN) network entities, the AF 1938 may use the communication facilities provided for the core network functions to notify the RAN controller device. When the RAN controller device receives this information, the controller may update the RAN nodes in different RAN subnets using the QoS configuration received from the AF 1938 in the core network.

[0161] After configuring the QoS information, the network device can start QoS management of the WebRTC session based on the configured parameter values. Each network device can notify the AF 1938 of the QoS status information at regular intervals. For the RAN node, the information will be transmitted to the AF 1938 through the RAN node. The interval for transmitting the QoS status information to the AF 1938 is configured by the application provider using the monitoring interval, which is the interval for reporting the QoS status information to the AF.

[0162] The QoS status information reported from each network device in each network subnet to AF 1938 may include a reporting time and reporting information. The reporting time is the time of the status report. The reporting information may include classification status, supervision status, propagation status, metering status, and queuing status. The classification status is a list of all classifications based on the configured classification information from the last time interval to the current time interval. The supervision status is the average bit rate, throughput, bandwidth, packet loss rate of each flow from the last time interval to the current time interval. The propagation status is the propagation type applied to each flow from the last time interval to the current time interval. The metering status is the metering applied to different flows from the last time interval to the current time interval. The queuing status is information about the current status of each queue, including the queuing scheme, the number of queues, the queue buffer size, the current and average congestion level, the scheduling status information, the current and average delay information, etc.

[0163] Based on the above status information, AF 1938 may have complete information of current QoS configuration and status information in MNO network 620. AF 1938 may update QoS configuration information based on the received QoS status information using the same service configuration process described previously in this disclosure.

[0164] Although Fig.19 An exemplary service configuration 1900 for an MNO-WebRTC service is shown, but may be used for Fig.19 Various changes may be made. For example, the number and placement of the various components of service configuration 1900 may vary as needed or desired. In addition, service configuration 1900 may be used for any other suitable media stream processing and is not limited to the specific processing described above.

[0165] Fig. 20 An exemplary QoS status notification 2000 of a WebRTC service to an application provider 2040 according to the present disclosure is shown. Fig. 20 The embodiment of QoS status notification 2000 shown in FIG. 2 is for illustration only. Fig. 20 The scope of the present disclosure is not limited to any particular implementation of a media streaming system.

[0166] like Fig. 20As shown, the QoS status information 2042 received by the AF 1938 from different network devices can be exchanged with the application provider 2040. Through the QoS status information 2042, the application provider 2040 is fully aware of the current QoS of all WebRTC sessions in the MNO network 620.

[0167] although Fig. 20 The QoS status notification 2000 of the WebRTC service to the application provider is shown, but it can be Fig. 20 Various modifications may be made. For example, the number and placement of the various components of QoS status notification 2000 may vary as needed or desired. In addition, QoS status notification 2000 may be used for any other suitable media stream processing and is not limited to the specific processing described above.

[0168] Fig.21 An exemplary end-to-end view 2100 of QOS according to the present disclosure is shown. Fig.21 The embodiment of the end-to-end view 2100 shown in FIG. 2 is for illustration only. Fig.21 The scope of the present disclosure is not limited to any particular implementation of a media streaming system.

[0169] like Fig.21 As shown, the WebRTC application provider 1936 has an end-to-end view 2100 of QoS. After the application service provider 1936 receives the QoS status information, the application service provider 1936 has a complete end-to-end view of the current QoS status and the configured QoS information. For example, for the inter-MNO WebRTC session described earlier in this disclosure, using the QoS status information from MNO-1 and MNO-2, the WebRTC application provider has a QoS view of MNO-1, MNO-2, and the intermediate transmission (e.g., the Internet) between the two MNOs.

[0170] although Fig.21 An exemplary end-to-end view 2100 of QOS is shown, but Fig.21 Various changes may be made. For example, the number and placement of the various components of the end-to-end view 2100 may vary as needed or desired. In addition, the end-to-end view 2100 may be used for any other suitable media stream processing and is not limited to the specific processing described above.

[0171] Fig. 22 An exemplary QoS compensation 2200 at network segments due to QoS degradation at different network segments according to the present disclosure is shown. Fig. 22 The embodiment of QoS compensation 2200 shown in FIG. 2 is for illustration only. Fig. 22 The scope of the present disclosure is not limited to any particular implementation of a media streaming system.

[0172] Once the application service provider has an end-to-end view 2100 of QoS for different MNO networks 620, the application service provider 1936 can use enhanced QoS configurations 2246 at different locations to compensate for QoS issues at one location.

[0173] like Fig. 22 As shown, after the application provider 1936 can receive the QoS status information 2244 and the application provider 1936 observes the QoS degradation at the first network segment 1102 (e.g., network segment-A), the application provider 1936 can provide an updated QoS configuration 2246 for the second network segment (e.g., network segment-B) to maintain end-to-end QoS for the WebRTC session. QoS compensation can occur not only for the network segment 1102, but also for all network devices and network functions involved in the QoS management of the WebRTC session.

[0174] although Fig. 22 An exemplary QoS compensation 2200 is shown, but may be Fig. 22 Various modifications may be made. For example, the number and placement of the various components of QoS compensation 2200 may vary as needed or desired. In addition, QoS compensation 2200 may be used for any other suitable media stream processing and is not limited to the specific processing described above.

[0175] Fig.23 Exemplary QoS compensation 2300 at different MNO networks according to the present disclosure is shown. Fig.23 The embodiment of QoS compensation 2300 shown in FIG. 2 is for illustration only. Fig.23 The scope of the present disclosure is not limited to any particular implementation of a media streaming system.

[0176] like Fig.23 As shown, QoS compensation 2300 can also occur at different MNOs. For example, for inter-MNO WebRTC services. QoS compensation 2300 can occur in different MNOs 620a and 620b. When the application provider 1936 receives information about the QoS degradation in MNO-1 620a, the application provider 1936 can provide an updated QoS configuration 2246 for the network device / function / segment in MNO-2 620b to maintain the end-to-end QoS of the WebRTC session. QoS compensation 2300 can be implemented using any method deemed necessary by the application provider, as described in Table 7 below.

[0177]

[0178] For example, a QoS compensation method that can be directly applied includes determining whether regulation in MNO-1 is lagging behind, and providing an updated QoS configuration with stricter regulation in MNO-2 so that the end-to-end QoS of the WebRTC session can be maintained.

[0179] Another QoS compensation method that can be directly applied includes determining if sufficient queuing cannot be applied in MNO-1 and providing an updated QoS configuration (e.g., number of queues, queue length) with a more stringent / relaxed queue policy in MNO-2 that can be applied to maintain end-to-end QoS. In addition, QoS compensation methods can be directly applied using classification information from MNO-2 to better enable QoS management of the same traffic in MNO-2, and vice versa.

[0180] In addition to using the above QoS scheme, the QoS compensation method 2300 can also be based on the media stream priority assigned by the WebRTC client 604. The application function 1938 can be informed by the WebRTC client 604 about the priority of different media streams. This information can then be forwarded to the application provider 1936. The application provider 1936 can receive media stream priority information from multiple MNOs. Then, for WebRTC sessions running between two users in the same MNO 620 and WebRTC sessions spanning more than one MNO 620, QoS compensation 2300 based on media stream priority can occur in different ways.

[0181] When a WebRTC session is running between two clients 604 in the same MNO 620, the priority information of the media stream at one WebRTC client 604 can affect the QoS configuration of different network segments / devices / links. For WebRTC sessions spanning more than one MNO 620 (e.g., for the inter-MNO WebRTC service described earlier in this disclosure), QoS reconfiguration can occur in any MNO 620.

[0182] QoS reconfiguration based on media stream priority can be achieved through higher supervision and metering values ​​for higher priority media streams and additional queues and enhanced queue configuration for higher priority media streams. In addition to the above methods, based on the end-to-end view 2100 of QoS information, the application provider 1936 is able to infer the QoS degradation caused by the Internet 1730 between the two MNOs 620a and 620b. Since the Internet 1730 is a best-effort QoS service, the Internet 1730 between the two MNOs 620a and 620b is likely to be the weakest link in end-to-end QoS management. The application functions 1938 in the MNOs 620a and 620b and the application providers 1936 cannot control the QoS configuration in the Internet 1730. In order to compensate for the QoS degradation caused by the Internet link between the two MNOs 620a and 620b, the QoS compensation method defined in the present disclosure can be applied to the two MNOs to have the closest end-to-end QoS required by the application provider 1936 as possible.

[0183] although Fig.23 Exemplary QoS compensation 2300 at different MNO networks is shown, but may be Fig.23 Various modifications may be made. For example, the number and placement of the various components of QoS compensation 2300 may vary as needed or desired. In addition, QoS compensation 2300 may be used for any other suitable media stream processing and is not limited to the specific processing described above.

[0184] Fig.24 An exemplary QoS compensation method 2400 at different MNO networks according to the present disclosure is shown. For ease of explanation, Fig.26 The method 2400 is described as using Fig.19 The method 2400 may be performed by the application provider 1936 and the AF 1938. However, the method 2400 may be used with any other suitable system and any other suitable electronic device.

[0185] like Fig.24 As shown, an end-to-end QoS management program can be provided for WebRTC sessions. The WebRTC application provider 1936 (service provider) can configure QoS information at the AF 1938 in step 2402. The AF 1938 can configure the QoS parameters of each of the network devices, links, and subnets in step 2404.

[0186] AF 1938 may receive QoS status information from each of the above entities in step 2406. AF 1938 may check the status information of each parameter, configuration option, QoS scheme, and method in step 2408. AF 1938 starts a loop of steps 2412 to 2420 for each of the QoS parameters, configuration options, QoS schemes, and methods in step 2410. AF 1938 may determine in step 2412 whether the last item has been processed to continue or end the method.

[0187] AF 1938 may determine in step 2416 whether the QoS parameters, configuration options, QoS schemes, and methods are within the expected range (e.g., are service level specifications being met?). If any QoS parameter / configuration option / QoS scheme / method is not performing as required or if QoS is degraded, AF 1938 may perform QoS compensation in step 2418. These steps are performed until all parameters, configuration options, QoS schemes, and methods have been checked, wherein the next QoS parameter, configuration option, QoS scheme, and method is retrieved in step 2420.

[0188] After checking all QoS parameters, configuration options, QoS schemes and methods, if end-to-end QoS is maintained, AF 1938 continues QoS monitoring. Otherwise, AF 1938 may continue to reconfigure QoS parameters, configuration options, QoS schemes and methods.

[0189] although Fig.24 An example of method 2400 for ensuring QoS for WebRTC sessions in a 5G network is shown, but may be used for Fig.24 Make various changes. For example, although Fig.24 The various steps in are shown as a series of steps, but they can overlap, occur in parallel, or occur any number of times.

[0190] Fig.25 Exemplary QoS compensation 2500 at different MNO networks according to the present disclosure is shown. Fig.25 The embodiment of QoS compensation 2500 shown in is for illustration only. Fig.25 The scope of the present disclosure is not limited to any particular implementation of a media streaming system.

[0191] The QoS management method includes where an application function 1938 in the network receives QoS status information and forwards it to an application provider 1936, and the application provider 1936 is responsible for QoS reconfiguration in one or more MNO networks 620. In some embodiments, the application function 1938 may perform the following tasks instead of the application provider 1936 performing QoS reconfiguration based on the inferred QoS status information.

[0192] Based on the QoS state information received from all QoS endpoints (e.g., networks, devices, segments, etc.), the AF can generate updated QoS configurations and reconfigure the QoS of those QoS endpoints. Even in this case, inferring new QoS configurations from QoS state information is similar to the way in which the application provider performs the same tasks described in the previous embodiments.

[0193] In the case where a WebRTC session spans more than one MNO, the AF 1938 in the MNO 620 can communicate directly with the AF 1938 in the peer MNO 620 to exchange "shielded" QoS state information, rather than passing the information through the application provider. When the peer AF 1938 receives such information, it can perform QoS reconfiguration as described above.

[0194] Methods are used to configure and reconfigure QoS parameters and the methods may be based on QoS state information received from QoS endpoints. In some embodiments, based on QoS state information received over a period of time, the QoS configuration responsible party (application provider or application function) may learn from changes in QoS statistics, state information, and inferred QoS configuration information to proactively update certain QoS configurations in different locations of the network or in different MNOs. Learning queue parameter configurations may proactively change queue configurations in peer MNOs (e.g., based on time of day, periodicity).

[0195] although Fig.25 Exemplary QoS compensation 2500 at different MNO networks is shown, but may be Fig.25 Various modifications may be made. For example, the number and placement of the various components of QoS compensation 2500 may vary as needed or desired. In addition, QoS compensation 2500 may be used for any other suitable media stream processing and is not limited to the specific processing described above.

[0196] Fig.26 An exemplary method 2600 for ensuring QoS for a WebRTC session in a 5G network according to the present disclosure is shown. For ease of explanation, Fig.26 The method 2600 is described as using Figure 2 and Figure 3 However, the method 2600 may be used with any other suitable system and any other suitable electronic device.

[0197] like Fig.26 As shown, the electronic device 300 may receive an expected level agreement (SLA) for a media service from a service provider at step 2602. The expected SLA is affected by different parameters of the WebRTC session. The expected SLA may include a suitable range or an acceptable performance percentage.

[0198] The electronic device 300 may provide a network slice including a media function based on the expected SLA at step 2604. In some embodiments, multiple network slices may be instantiated for a WebRTC session. Signaling data, media data, and data channel traffic may be routed through one or more slices. Each of the signaling data, media data, and data channel traffic may be routed through a separate slice.

[0199] The electronic device 300 may configure the media functions in the network slice using the traffic prioritization information for each media flow of the media service at step 2606. Traffic prioritization may include implementing priority queues at different network functions in the network slice and providing queue configurations of the priority queues that prioritize the media flows in the network slice. Traffic prioritization may also include determining a priority level for each priority queue based on the queue configuration; configuring at least one of latency, bandwidth, and throughput for each priority queue based on the priority level of each priority queue, wherein a higher priority level configures a priority queue with at least one of smaller latency, higher bandwidth, and higher throughput; and transmitting each media flow through the priority queue based on the priority level of the media flow.

[0200] Traffic prioritization may also include configuring network segments in the network slice with different parameters based on the priority level of each network segment; and transmitting the media streams through the network segments based on the priority level of the media streams. Traffic prioritization may be different for media streams of the same media type.

[0201] The electronic device 300 may determine the performance of the media stream at step 2608. The client 604 communicates using WebRTC, and the application provider 1936 and the AF 1938 may monitor the QoS. The performance may be continuously or periodically monitored to obtain the expected QoS.

[0202] At step 2610, the electronic device 300 may perform an adjustment of a service parameter based on determining that the performance of the media stream is below the expected SLA. An adjustment of each SLA parameter may be calculated so that the performance meets the expected SLA. A list of adjustments to be performed may be generated based on the calculated adjustments of each SLA parameter.

[0203] A first adjustment in the adjustment list corresponding to the SLA parameter with the highest priority may be applied. The performance may be measured after a predetermined amount of time has elapsed. When the measured performance does not meet the expected SLA, a second adjustment in the adjustment list corresponding to the SLA parameter with the second highest priority may be applied.

[0204] although Fig.26An example of method 2600 for ensuring QoS for WebRTC sessions in a 5G network is shown, but may be used for Fig.26 Make various changes. For example, although Fig.26 The various steps in are shown as a series of steps, but they can overlap, occur in parallel, or occur any number of times.

[0205] Fig. 27 A block diagram of a terminal (or user equipment (UE)) according to an embodiment as disclosed herein is shown.

[0206] like Fig. 27 As shown, the terminal according to the embodiment may include a transceiver 2710, a memory 2720 and a processor (or controller) 2730. The transceiver 2710, the memory 2720 and the processor (or controller) 2730 of the terminal may operate according to the communication method of the above-mentioned terminal. However, the components of the terminal are not limited thereto. For example, the terminal may include Fig. 27 2700, the transceiver 2710, and the memory 2720 may be implemented as a single chip. In addition, the processor (or controller) 2730 may include at least one processor. In addition, the terminal corresponds to Figure 1 Client devices 106 to 116, Figure 4 UE 402, Figure 6 The browser client 604.

[0207] Transceiver 2710 refers to a terminal station receiver and a terminal transmitter collectively, and can transmit a signal to a base station or another terminal / receive a signal from a base station or another terminal. The signal transmitted to or received from the terminal may include control information and data. Transceiver 2710 may include an RF transmitter for up-converting and amplifying the transmitted signal, and an RF receiver for low-noise amplification of the received signal and down-converting. However, this is only an example of transceiver 2710, and the components of transceiver 2710 are not limited to RF transmitters and RF receivers.

[0208] In addition, the transceiver 2710 may receive a signal through a wireless channel and output it to the processor 2730 , and transmit a signal output from the processor (or controller) 2730 through a wireless channel.

[0209] The memory 2720 may store programs and data required for the operation of the terminal. In addition, the memory 2720 may store control information or data included in a signal obtained by the terminal. The memory 2720 may be a storage medium such as a read-only memory (ROM), a random access memory (RAM), a hard disk, a CD-ROM, and a DVD, or a combination of storage media.

[0210] The processor (or controller) 2730 may control a series of processes so that the terminal operates as described above. For example, the processor (or controller) 2730 may receive a data signal and / or a control signal, and the controller 2730 may determine a result of receiving a signal transmitted by a base station and / or other terminals.

[0211] Fig.28 A block diagram of a base station (BS) according to embodiments as disclosed herein is shown.

[0212] like Fig.28 As shown, the base station of the present disclosure may include a transceiver 2810, a memory 2820, and a processor (or controller) 2830. The transceiver 2810, the memory 2820, and the processor (or controller) 2830 of the base station may operate according to the communication method of the above-mentioned base station. However, the components of the base station are not limited thereto. For example, the base station may include Fig.28 28. In addition, the processor (or controller) 2830, the transceiver 2810, and the memory 2820 may be implemented as a single chip. In addition, the processor (or controller) 2830 may include at least one processor. In addition, the base station corresponds to the base station 118, Figure 1 The cellular base station 120 and Figure 6 gNB 606.

[0213] The transceiver 2810 collectively refers to a base station receiver and a base station transmitter, and can transmit signals to / receive signals from a terminal, another base station, and / or a core network function (or entity). The signals transmitted to or received from the base station may include control information and data. The transceiver 2810 may include an RF transmitter for up-converting and amplifying the transmitted signal, and an RF receiver for low-noise amplification and down-conversion of the received signal. However, this is only an example of the transceiver 2810, and the components of the transceiver 2810 are not limited to the RF transmitter and the RF receiver.

[0214] In addition, the transceiver 2810 may receive a signal through a wireless channel and output it to the processor 2830 , and transmit a signal output from the processor (or controller) 2830 through a wireless channel.

[0215] The memory 2820 may store programs and data required for the operation of the base station. In addition, the memory 2820 may store control information or data included in a signal obtained by the base station. The memory 2820 may be a storage medium such as a ROM, RAM, hard disk, CD-ROM, and DVD, or a combination of storage media.

[0216] The processor (or controller) 2830 may control a series of processes so that the base station operates as described above. For example, the processor (or controller) 2830 may receive a data signal and / or a control signal, and the processor (or controller) 2830 may determine the result of receiving a signal transmitted by a terminal and / or a core network function.

[0217] Fig.29 A block diagram of a network entity (NE) according to embodiments as disclosed herein is shown.

[0218] like Fig.29 As shown, the network entity of the present disclosure may include a transceiver 2910, a memory 2920, and a processor 2930. The transceiver 2910, the memory 2920, and the processor 2930 of the network entity may operate according to the communication method of the above-mentioned network entity. However, the components of the terminal are not limited thereto. For example, the network entity may include more or fewer components than the above-mentioned components. In addition, the processor 2930, the transceiver 2910, and the memory 2920 may be implemented as a single chip. In addition, the processor 2930 may include at least one processor. In addition, the network entity corresponds to Figure 4 PCF 406 or DN 404, Fig. 9 Edge UPF 924, Fig.16 AF 1624 and Fig.19 , Fig. 20 , Fig. 22 , Fig.23 or Fig.25 AF 1938.

[0219] The transceiver 2910 is collectively referred to as a network entity receiver and a network entity transmitter, and can transmit signals to / receive signals from a base station or a UE. The signals transmitted to or received from a base station or a UE may include control information and data. In this regard, the transceiver 2910 may include an RF transmitter for up-converting and amplifying the transmitted signal, and an RF receiver for low-noise amplification and down-conversion of the received signal. However, this is only an example of the transceiver 2910, and the components of the transceiver 2910 are not limited to the RF transmitter and the RF receiver.

[0220] In addition, the transceiver 2910 may receive a signal through a wireless channel and output it to the processor 2930 , and transmit a signal output from the processor 2930 through a wireless channel.

[0221] The memory 2920 may store programs and data required for the operation of the network entity. In addition, the memory 2920 may store control information or data included in a signal obtained by the network entity. The memory 2920 may be a storage medium such as a ROM, RAM, hard disk, CD-ROM, and DVD, or a combination of storage media.

[0222] The processor 2930 may control a series of processes so that the network entity operates as described above.For example, the transceiver 2910 may receive a data signal including a control signal, and the processor 2930 may determine a result of receiving the data signal.

[0223] The methods according to the embodiments described in the claims or the detailed description of the present disclosure may be implemented by hardware, software, or a combination of hardware and software.

[0224] When the electrical structure and method are implemented in software, a computer-readable recording medium having one or more programs (software modules) recorded thereon may be provided. The one or more programs recorded on the computer-readable recording medium are configured to be executable by one or more processors in an electronic device. The one or more programs include instructions for executing the methods of the embodiments described in the claims or the detailed description of the present disclosure.

[0225] The program (e.g., software module or software) may be stored in random access memory (RAM), non-volatile memory, including flash memory, read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic disk storage device, compact disk-ROM (CD-ROM), digital versatile disk (DVD), another type of optical storage device, or magnetic tape cassette. Alternatively, the program may be stored in a memory system that includes a combination of some or all of the aforementioned memory devices. In addition, the individual memory devices may be included in the plural.

[0226] The program may also be stored in an attachable storage device that is accessible via a communication network such as the Internet, an intranet, a local area network (LAN), a wireless LAN (WLAN), or a storage area network (SAN), or a combination thereof. The storage device may be connected to an apparatus according to an embodiment of the present disclosure via an external port. Another storage device on the communication network may also be connected to an apparatus that performs an embodiment of the present disclosure.

[0227] In the foregoing embodiments of the present disclosure, the elements included in the present disclosure are expressed in singular or plural form according to the embodiments. However, singular or plural form is appropriately selected for ease of explanation, and the present disclosure is not limited thereto. Therefore, the elements expressed in plural form may also be configured as a single element, and the elements expressed in singular form may also be configured as multiple elements.

[0228] Although the drawings illustrate different examples of user equipment, various changes may be made to the drawings. For example, the user equipment may include any number of each component in any suitable arrangement. Generally, the drawings do not limit the scope of the present disclosure to any particular configuration. In addition, although the drawings illustrate operating environments in which various user equipment features disclosed in this patent document may be used, these features may be used in any other suitable system.

[0229] At least some of the exemplary embodiments described herein may be constructed in part or in whole using dedicated, special-purpose hardware. Terms such as "components", "modules" or "units" used herein may include, but are not limited to, hardware devices, such as circuits in the form of discrete or integrated components, field programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs), which perform certain tasks or provide associated functions. In some embodiments, the described elements may be configured to reside on a tangible, persistent, addressable storage medium, and may be configured to be executed on one or more processors. In some embodiments, for example, these functional elements include components such as software components, object-oriented software components, class components, and task components, processes, functions, attributes, procedures, subroutines, program code segments, drivers, firmware, microcodes, circuits, data, databases, data structures, tables, arrays, and variables. Although exemplary embodiments have been described with reference to the components, modules, and units discussed herein, such functional elements may be combined into fewer components or separated into additional components. Various combinations of optional features have been described herein, and it will be understood that the described features may be combined in any suitable combination. Specifically, the features of any one exemplary embodiment may be appropriately combined with the features of any other embodiment unless such combinations are mutually exclusive. Throughout the specification, the terms “comprising” or “comprises” mean including specified components but not excluding the existence of other components.

[0230] Attention is paid to all documents and references filed concurrently with or prior to this application in connection with this application and which are open to public inspection with this specification, and the contents of all such documents and references are incorporated herein by reference.

[0231] All features disclosed in this specification (including any accompanying claims, abstract and drawings) and / or all steps of any method or process so disclosed may be combined in any combination, except combinations where at least some of the features and / or steps are mutually exclusive.

[0232] Unless expressly stated otherwise, each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose. Therefore, unless expressly stated otherwise, each feature disclosed is only one example of a general series of equivalent or similar features.

[0233] The present invention is not limited to the details of the foregoing embodiments. The present invention extends to any novel feature or any novel combination of the features disclosed in this specification (including any attached claims, abstract and drawings), or to any novel step or any novel combination of the steps of any method or process disclosed in this specification (including any attached claims, abstract and drawings).

[0234] Although the present disclosure has been described with exemplary embodiments, various changes and modifications may be proposed to those skilled in the art. The present disclosure is intended to include such changes and modifications that fall within the scope of the appended claims. Any description in this application should not be construed as implying that any particular element, step or function is an essential element that must be included within the scope of the claims. The scope of the patent subject matter is defined by the claims.

Claims

1. A device comprising: at least one transceiver; as well as a controller coupled to the at least one transceiver and configured to: receiving an expected service level agreement (SLA) for a media service from a service provider, wherein the media service includes a plurality of media streams; Providing a network slice including media functions based on the expected SLA; configuring the media function in the network slice using traffic prioritization information for each of the plurality of media flows; Determining the performance of each media stream; and Based on determining that the performance of one or more media flows is below the expected SLA, an adjustment of a service parameter is performed.

2. The device according to claim 1, wherein: The controller is also configured to: implementing priority queues at different network functions in the network slice; and Provide a queue configuration for the priority queue, and the priority queue prioritizes the media streams in the network slice.

3. The device as claimed in claim 2, wherein: The controller is also configured to: determining a priority level for each priority queue based on the queue configuration; configuring at least one of delay, bandwidth, and throughput for each priority queue based on a priority level of each priority queue, wherein a higher priority level configures a priority queue with at least one of less delay, higher bandwidth, and higher throughput; as well as Each media stream is transmitted through the priority queue based on the priority level of the media stream.

4. The device according to claim 1, wherein: The controller is also configured to: configuring the network segments in the network slice with different parameters based on the priority level of each network segment; and The media stream is transmitted through the network segment based on a priority level of the media stream.

5. A method performed by an apparatus, comprising: receiving an expected service level agreement (SLA) for a media service from a service provider, wherein the media service includes a plurality of media streams; Providing a network slice including media functions based on the expected SLA; configuring the media function in the network slice using traffic prioritization information for each of the plurality of media flows; Determining the performance of each media stream; and Based on determining that the performance of one or more media flows is below the expected SLA, an adjustment of a service parameter is performed.

6. The method of claim 5, further comprising: Implementing priority queues at different network functions in the network slice; as well as Provide a queue configuration for the priority queue, and the priority queue prioritizes the media streams in the network slice.

7. The method of claim 6, further comprising: determining a priority level for each priority queue based on the queue configuration; configuring at least one of delay, bandwidth, and throughput for each priority queue based on a priority level of each priority queue, wherein a higher priority level configures a priority queue with at least one of less delay, higher bandwidth, and higher throughput; as well as Each media stream is transmitted through the priority queue based on the priority level of the media stream.

8. The method of claim 5, further comprising: configuring the network segments in the network slice with different parameters based on the priority level of each network segment; as well as The media stream is transmitted through the network segment based on a priority level of the media stream.

9. A service provider, comprising: at least one transceiver; as well as a controller coupled to the at least one transceiver and configured to: transmitting an expected service level agreement (SLA) for the media service to the device; wherein the expected SLA is related to a network slice including the media function being provided, wherein the media function in the network slice is configured using traffic prioritization information for each of a plurality of media flows, and The adjustment of the service parameters is performed based on a determination that the performance of one or more media streams is below the expected SLA.

10. The service provider according to claim 9, in, Priority queues at different network functions in the network slice are implemented, and Wherein, a queue configuration of the priority queue is provided, and the priority queue prioritizes the media streams in the network slice.

11. The service provider according to claim 10, in, The priority level of each priority queue is based on the configuration of said queue; wherein at least one of a delay, a bandwidth, and a throughput of each priority queue is based on a priority level of each priority queue, wherein a higher priority level configures a priority queue with at least one of a smaller delay, a higher bandwidth, and a higher throughput; and Each media stream passing through the priority queue is transmitted based on the priority level of the media stream.

12. The service provider according to claim 9, in, The network segments with different parameters in the network slice are configured based on the priority level of each network segment; and The media stream passing through the network segment is transmitted based on a priority level of the media stream.

13. A method performed by a service provider, the method comprising: transmitting an expected service level agreement (SLA) for the media service to the device; wherein the expected SLA is related to a network slice including the media function being provided, wherein the media function in the network slice is configured using traffic prioritization information for each of a plurality of media flows, and The adjustment of the service parameters is performed based on a determination that the performance of one or more media streams is below the expected SLA.

14. The method according to claim 13, in, Priority queues at different network functions in the network slice are implemented, and Wherein, a queue configuration of the priority queue is provided, and the priority queue prioritizes the media streams in the network slice.

15. The method of claim 14, in, The priority level of each priority queue is based on the configuration of said queue; wherein at least one of a delay, a bandwidth, and a throughput of each priority queue is based on a priority level of each priority queue, wherein a higher priority level configures a priority queue with at least one of a smaller delay, a higher bandwidth, and a higher throughput; and Each media stream passing through the priority queue is transmitted based on the priority level of the media stream.

Images