Method and apparatus for grouping media streams in real-time communication service

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting higher data transmission rates and satisfying various service requirements. The disclosure provides a method performed by a terminal in a wireless communication system. The method comprises the steps of: receiving service guide information from an application provider, the service guide information being used to acquire information configuration information for requesting a configuration of a dynamic policy to be applied to a media transmission session of a real-time communication service; establishing, on the basis of negotiation with an RTC endpoint participating in the real-time communication service, the media transmission session including at least one media stream; and transmitting, to an application function (AF), a request for configuration of the dynamic policy, wherein the request includes identification information of the at least one media stream and a quality of service (QoS) requirement for the at least one media stream, and the identification information and the QoS requirement can be determined on the basis of the negotiation.

Description

Method and device for media stream grouping in real-time communication services

[0001] The present disclosure relates to the operation of a terminal and a network in a wireless communication system (or, mobile communication system). Specifically, the present disclosure relates to a packet processing method and apparatus considering media characteristics.

[0002] 5G mobile communication technology defines wide frequency bands to enable fast transmission speeds and new services, and can be implemented not only in sub-6GHz bands such as 3.5 GHz ('Sub 6GHz') but also in ultra-high frequency bands known as millimeter wave (mmWave), such as 28GHz and 39GHz ('Above 6GHz'). Furthermore, for 6G mobile communication technology, which is referred to as a system beyond 5G, it is expected to become crucial to secure new frequency resources—including not only the 5G Sub 6GHz and ultra-high frequency bands but also the mid-frequency band (7-24 GHz), known as the Upper Mid band—and to efficiently utilize all available frequency resources as needed. This is necessary to handle the surge in data traffic driven by the spread of AI (artificial intelligence) technology and the increase in streaming services, and to improve user experience. To this end, reallocation, reuse, or sharing of existing frequency bands from 2G to 5G for 6G may also be considered. Separately, since the introduction of 5G, the telecommunications market has shown increasing interest in system operation efficiency, sustainability, and user experience improvement. Accordingly, not only are improvements in traditional communication performance, such as data transmission speed and latency, becoming increasingly important, but the introduction of new innovative technologies such as AI, reduction of operating costs, improvement of energy efficiency, expansion of service coverage, and introduction of new services are also becoming more critical.

[0003] In the early stages of 5G mobile communication technology, aiming to satisfy service support and performance requirements for enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC), and massive machine-type communications (mMTC), technologies included beamforming and massive MIMO to mitigate path loss and increase propagation distance in ultra-high frequency bands; support for various numerologies (such as operating multiple subcarrier spacings) and dynamic operation of slot formats for the efficient utilization of ultra-high frequency resources; initial access technologies to support multi-beam transmission and broadband; definition and operation of band-width parts (BWPs); new channel coding methods such as low-density parity check (LDPC) codes for high-volume data transmission and polar codes for reliable transmission of control information; L2 pre-processing; and networks providing dedicated networks specialized for specific services. Standardization of network slicing and the like has been carried out.

[0004] Since the early days of 5G mobile communication technology, discussions have been held regarding the improvement and enhancement of the initial technology, taking into account the services that 5G technology was intended to support. These include V2X (vehicle-to-everything), which assists autonomous vehicles in making driving decisions and enhances user convenience based on location and status information transmitted by vehicles; NR-U (new radio unlicensed), which aims for system operation compliant with various regulatory requirements in unlicensed bands; UE power saving technology for NR terminals; non-terrestrial network (NTN), a direct terminal-satellite communication for securing coverage in areas where communication with terrestrial networks is impossible; positioning; supporting NR operation up to 71 GHz; support of reduced capability NR devices for lower cost and complexity compared to general terminals; UE power saving enhancement for improved power management in preparation for the utilization of various terminal types; and sidelink enhancement. Evolution of redundancy technology (duplex enhancements) researching a new form of duplex method called subband non-overlapping full duplex (SBFD), network energy saving that maximizes idle periods during which base stations operate in maximum power saving mode and reduces power consumption,Physical layer standardization was conducted for technologies such as network-controlled repeaters, which have improved performance compared to existing repeaters by being equipped with the function of receiving and processing side control information from the network.

[0005] Furthermore, the standardization of Intelligent Factories (Industrial Internet of Things, IIoT) to support new services through linkage and convergence with other industries; Integrated Access and Backhaul (IAB), which provides nodes to expand network service areas by integrating wireless backhaul and access links; Mobility Enhancement technologies including Conditional Handover and Dual Active Protocol Stack (DAPS) Handover; 2-step Random Access for Non-Release (RACH for NR) to simplify random access procedures; multicast and broadcast; support for multi-USIM devices that provide services to users using information from two or more SIMs; sidelink relay, which provides relay-related functions to support connections between terminals at long distances and between terminals and networks; Small Data Transmission (SDT in an inactive state), which transmits small data or signaling in an inactive state without transitioning to a connection state; and Layer 1 / L2 Triggered Mobility (LTM) / Continuous Conditional Standardization of the wireless interface architecture / protocol layer for technologies such as mobility enhancements including subsequent conditional PSCell addition / change (SCAC) and conditional handover with candidate SCGs (CHO with candidate SCGs), and XR enhancements to support XR services in NR systems has also been carried out,Systems regarding 5G baseline architectures for integrating Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies (e.g., service-based architecture, service-based interface); Mobile Edge Computing (MEC), which provides services based on the terminal's location; Non-Public Networks (NPN), which are accessible only to authorized terminals for non-public purposes; Disaster Roaming, which supports the use of communication services through other carrier networks in the event of a telecommunications disaster; Proximity-Based Service via 5GS; Support for Uncrewed Aerial Vehicles (UAVs) to assist with remote identification, tracking, and authorization; Architecture enhancements to support XR and interactive media services; 5GS for supporting AI / ML (artificial intelligence / machine learning) services; and Advanced Mobile Edge Computing, which provides edge computing services on roaming networks. Standardization in the architecture / service fields also proceeded.

[0006] Currently, at the physical layer, standardization is underway for technologies such as beam prediction using AI / ML technology, CSI (channel state information) prediction for improved positioning accuracy, ultra-low power terminal technology using low-power wake-up receivers, technology for transmitting LTE (long term evolution) broadcasts to 5G networks, MIMO transmission technology using multiple base stations, and ambient IoT, which transmits data by acquiring power from an external source without a battery. At the wireless interface architecture / protocol layer, standardization is underway for supporting LTM scenarios between Central Units (CUs) and conditional LTM, supporting the same XR service simultaneously among multiple devices, improving and evolving NTN coverage, supporting mobility based on AI / ML, and relaying connections between terminals across multiple hops between terminals and networks. In addition, standardization is underway in the fields of system architecture and services regarding communication optimization methods for satellites, energy usage management and efficiency of 5G systems, user plane evolution based on SBI, Ambient IoT technology, data service provision methods in IMS (IP multimedia subsystem), and avatar communication services. Once such 5G mobile communication systems are commercialized, connected devices, which are increasing explosively, will be connected to communication networks; accordingly, it is expected that there will be a need to enhance the functions and performance of 5G mobile communication systems and to integrate the operation of connected devices.To this end, additional new research is planned to be conducted on eXtended Reality (XR) to efficiently support augmented reality (AR), virtual reality (VR), mixed reality (MR), 5G performance improvement and complexity reduction using AI / ML, support for AI services, support for metaverse services, and drone communication.

[0007] Furthermore, the advancement of these 5G mobile communication systems is expected to enhance 5G performance while serving as the foundation for the ultimate evolution into 6G. In the 6G era, the three major 5G services mentioned earlier—eMBB, URLLC, and mMTC—are expected to evolve and expand into immersive communication (IC), hyper-reliable and low-latency communication (HRLLC), and massive communication (MC), respectively. In addition, new services such as AI-integrated communication, integrated sensing and communication, and ubiquitous connectivity are planned to be additionally supported. Enhanced performance requirements compared to 5G are essential for these diverse 6G services, and standardization to define these requirements is currently underway.

[0008] As such, in order to satisfy the expanded services and enhanced performance requirements of 6G, it is expected that not only will existing communication performance be improved, but system operations will also be optimized and streamlined through the introduction of AI technology, improved energy efficiency, expanded coverage, and the application of next-generation security technology, and the development of sustainable communication technology will be essential.

[0009] To this end, AI internalization technology that applies the latest AI technology across all areas from the communication system design stage to development, management, and operation to realize improved communication performance and network automation and efficiency; technology to improve user perceived performance and network operational efficiency by reducing power consumption of networks and terminals; technology to reduce power consumption in core base station components such as RF (radio frequency) and modems, as well as in channel coding and signal modulation / demodulation transmission and reception processes; multi-antenna transmission technology (eXtreme MIMO, X-MIMO) utilizing large-scale antennas to overcome propagation path loss caused by frequencies higher than the 3.5GHz band of 5G communication and provide equivalent coverage; multi-base station-based transmission and reception technology (distributed MIMO, D-MIMO) to improve quality in cell boundary areas; sub-band non-overlapping full duplex (SBFD) technology for enhancing frequency efficiency and system networks; next-generation encryption technology (post-quantum cryptography, PQC) and zero trust architecture (ZTA) technology to strengthen 6G communication security; and initial connection delay and mobility delay Research will be conducted intensively on minimization techniques, the design of hardware-friendly protocol structures for ultra-high-speed data processing, and the expanded application of integrity protection techniques.

[0010] In addition, research is planned on the structure of mobile communication systems (prevention of redundant functions, function simplification, etc.), the introduction of new planes for operator service provision, measures for protecting user privacy, immersive services, enhancement of network resiliency, network sharing technology, enhanced security technology (false base station, lower layer protection, etc.), and intent-based network operation and management.

[0011] Meanwhile, content related to extended reality (XR) is expected to be utilized in various fields such as healthcare and manufacturing. To utilize this effectively, technology capable of transmitting large volumes of various media data formats (e.g., graphical objects, audio, video, haptic) in real time is required. Since the various media data formats mentioned above can each have different transmission characteristics, discussions are ongoing regarding how to effectively process media data and allocate network resources by reflecting these characteristics.

[0012] One objective of the present disclosure is to provide a method for allocating network resources by media and applying network policies for real-time communication services in a mobile communication system.

[0013] In addition, one objective of the present disclosure is to provide a method and apparatus for requesting a QoS flow optimized for each media stream by taking into account the transmission characteristics of each media stream.

[0014] Alternatively, one object of the present disclosure is to provide a method and apparatus for allocating network resources by grouping media streams having the same QoS requirements.

[0015] The technical problems to be solved in the various embodiments of the present disclosure are not limited to those mentioned above, and other technical problems not mentioned may be considered by those skilled in the art from the various embodiments of the present disclosure described below.

[0016] A method of a service control device for supporting a real-time communication service in a mobile communication system according to an example of the present disclosure for solving the above-mentioned problems may include: receiving real-time communication service setting information from an application service provider; receiving detailed information of a media stream for a real-time communication service from a user terminal or server; and providing network setting information for a real-time communication service to a network.

[0017] A method performed by a terminal in a wireless communication system according to one example of the present disclosure comprises: receiving service guidance information from an application provider; obtaining setting information for requesting the setting of a dynamic policy to be applied to a media transmission session of a real-time media communication (RTC) service based on the service guidance information; establishing the media transmission session including at least one media stream based on negotiation with an RTC endpoint participating in the real-time media communication service; and transmitting a request for the setting of the dynamic policy to an application function (AF); wherein the request includes identification information of the at least one media stream and a quality of service (QoS) requirement for the at least one media stream, and the identification information and the QoS requirement may be determined based on the negotiation.

[0018] A method performed by an application function (AF) in a wireless communication system according to one example of the present disclosure comprises: establishing a provisioning session associated with a dynamic policy to be applied to a media transmission session of a real-time media communication (RTC) service with an application provider; receiving a request for setting the dynamic policy from a terminal, wherein the request includes identification information of at least one media stream included in the media transmission session and a quality of service (QoS) requirement for the at least one media stream, and the identification information and the QoS requirement are received based on negotiation between the terminal and the RTC endpoint; and transmitting a request for QoS provision associated with the dynamic policy to a policy control function (PCF); wherein the request for QoS provision may include the identification information and the QoS requirement.

[0019] A terminal in a wireless communication system according to one example of the present disclosure comprises: a transceiver; at least one processor connected to the transceiver so as to be able to communicate with the transceiver; and a memory connected to the at least one processor so as to be able to communicate with the at least one processor and executable by the at least one processor, wherein the terminal receives service guidance information from an application provider and obtains configuration information for requesting the configuration of a dynamic policy to be applied to a media transmission session of a real-time media communication (RTC) service based on the service guidance information, establishes the media transmission session including at least one media stream based on negotiation with an RTC endpoint participating in the real-time media communication service, and stores an instruction that causes the request for the configuration of the dynamic policy to be transmitted to an application function (AF); wherein the request includes identification information of the at least one media stream and a quality of service (QoS) requirement for the at least one media stream, and the identification information and the QoS requirement may be determined based on the negotiation.

[0020] In a wireless communication system according to one example of the present disclosure, an application function (AF) comprises: a transceiver; and at least one processor connected to the transceiver so as to be able to communicate. and connected to communicate with at least one processor and executable by the at least one processor, wherein the AF establishes a provisioning session associated with a dynamic policy to be applied to a media transmission session of a real-time media communication (RTC) service with an application provider, and receives a request for the setting of the dynamic policy from a terminal, wherein the request includes identification information of at least one media stream included in the media transmission session and a quality of service (QoS) requirement for the at least one media stream, wherein the identification information and the QoS requirement are received based on negotiation between the terminal and the RTC endpoint, and a memory storing a command that causes a request for QoS provision associated with the dynamic policy to be transmitted as a policy control function (PCF); wherein the request for QoS provision may include the identification information and the QoS requirement.

[0021] The various examples of the present disclosure described above are merely some of the preferred embodiments of the present disclosure, and various embodiments reflecting the technical features of the various examples of the present disclosure can be derived and understood by those skilled in the art based on the detailed description to be described below.

[0022] The existing QoS request method using SDP (Session Description Protocol) is defined as allocating resources and applying packet processing policies to media data at the level of media transmission sessions (or IP (Internet Protocol) flows), which had a problem in that it could not consider the individual transmission characteristics of multiple media streams included within a single media transmission session when mapping media data to QoS.

[0023] However, according to one example of the present disclosure, an AF (e.g., media AF or P-CSCF) can transmit information regarding QoS requirements for each media stream to a network, and the network can configure a QoS flow optimized for the transmission characteristics of each media stream, thereby enabling the network to communicate while reflecting the requirements of each media stream.

[0024] In addition, according to one example of the present disclosure, by grouping media streams having the same QoS requirements to configure QoS flows, there is an effect of efficiently allocating limited network resources.

[0025] The effects obtainable from the various embodiments of the present disclosure are not limited to those mentioned above, and other unmentioned effects can be clearly derived and understood by those skilled in the art based on the following detailed description.

[0026] To more clearly explain the technical methods of the embodiments proposed in this disclosure, the drawings of the embodiments are briefly introduced. The following drawings are for reference only to the embodiments of this disclosure and are not intended to limit this disclosure.

[0027] FIG. 1 is a 5G system structure for media services in a wireless communication system according to the present disclosure (5 thThis is a conceptual diagram illustrating the Generation system (5GS).

[0028] FIG. 2 is a diagram illustrating an example of a method for providing quality of service (QoS) per media stream in a wireless communication system according to the present disclosure.

[0029] FIG. 3 is a conceptual diagram illustrating an example of a packet structure for transmitting a media stream using the real-time transport protocol (RTP) in a wireless communication system according to the present disclosure.

[0030] FIG. 4 is a conceptual diagram illustrating a conceptualized Generalized Media Delivery Architecture for providing media services in a wireless communication system according to the present disclosure.

[0031] FIG. 5 is a diagram illustrating an example of a media service provision procedure in a wireless communication system following a conceptualized media transmission structure according to the present disclosure.

[0032] FIG. 6 is a diagram illustrating an IMS (IP (internet protocol) multimedia subsystem) network structure for providing real-time communication services in a wireless communication system according to the present disclosure.

[0033] FIG. 7 is a diagram illustrating a service initiation procedure using SIP (session initiation protocol) in a real-time communication service according to one embodiment of the present disclosure.

[0034] FIG. 8 is a diagram illustrating the session description protocol (SDP) negotiation procedure of a real-time communication service in a wireless communication system according to one embodiment of the present disclosure.

[0035] FIG. 9 is a diagram illustrating an SDP including quality of service (QoS) requirements per media transmission session according to one embodiment of the present disclosure.

[0036] FIG. 10 is a diagram illustrating an SDP including QoS requirements per media description according to one embodiment of the present disclosure.

[0037] FIG. 11 is a diagram illustrating an SDP including QoS requirements per RTP stream and / or RTP stream group according to one embodiment of the present disclosure.

[0038] FIG. 12 is a block diagram illustrating the structure of a user terminal according to one embodiment of the present disclosure.

[0039] FIG. 13 is a block diagram illustrating a network entity according to one embodiment of the present disclosure.

[0040] Embodiments of the present disclosure will be described in detail below with reference to the attached drawings.

[0041] In describing the embodiments, if a detailed description of a known function or configuration related to the present disclosure could unnecessarily obscure the essence of the present disclosure, such detailed description will be omitted.

[0042] For the same reason, some components in the attached drawings have been exaggerated, omitted, or schematically depicted. Additionally, the size of each component does not entirely reflect its actual dimensions. Identical or corresponding components in each drawing have been assigned the same reference number.

[0043] The advantages and features of the present disclosure and the methods for achieving them will become clear by referring to the embodiments described below in detail together with the accompanying drawings.

[0044] Furthermore, the present disclosure is not limited to the embodiments disclosed below but may be implemented in various different forms, and the embodiments provided merely to complete the configuration of the present disclosure and to fully inform those skilled in the art of the scope of the invention, and the present disclosure is defined only by the scope of the claims. Throughout the specification, the same reference numerals refer to the same components.

[0045] It will be understood that each block of the process flow diagrams and combinations of the flow diagrams can be executed by computer program instructions. Since these computer program instructions can be loaded into the processor of a general-purpose computer, a specialized computer, or other programmable data processing equipment, the instructions executed through the processor of the computer or other programmable data processing equipment create means to perform the functions described in the flow diagram block(s). Since these computer program instructions can also be stored in computer-available or computer-readable memory that can be directed toward the computer or other programmable data processing equipment to implement the function in a specific way, the instructions stored in such computer-available or computer-readable memory can also produce a manufactured item containing the means of instruction to perform the function described in the flow diagram block(s). Since computer program instructions can be loaded onto a computer or other programmable data processing equipment, instructions that perform a series of operations on the computer or other programmable data processing equipment to create a process executed by the computer can also provide operations for executing the functions described in the flowchart block(s).

[0046] Additionally, each block may represent a module, segment, or part of code containing one or more executable instructions for executing a specified logical function(s). It should also be noted that in some alternative execution examples, the functions mentioned in the blocks may occur out of order. For instance, two blocks described in succession may actually be executed substantially simultaneously, or the blocks may be executed in reverse order according to their corresponding functions.

[0047] In this embodiment, the term "part" refers to a software or hardware component, such as an FPGA or ASIC, and the "part" performs certain roles. However, the meaning of "part" is not limited to software or hardware. The "part" may be configured to reside in an addressable storage medium and may be configured to run one or more processors. Thus, as an example, the "part" includes components such as software components, object-oriented software components, class components, and task components, as well as processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided within the components and "parts" may be combined into a smaller number of components and "parts" or further separated into additional components and "parts." In addition, the components and '~parts' may be implemented to play one or more CPUs within the device or secure multimedia card.

[0048] For the convenience of the following description, some terms and names defined in 3GPP (3rd generation partnership project) standards (specifications for 5G, NR, LTE, or similar systems) may be used. Additionally, terms and names newly defined in next-generation communication systems to which this disclosure applies (e.g., 6G, Beyond 5G systems) or used in existing communication systems may be used. The use of such terms is not limited by the terms and names of this disclosure and may be applied equally to systems conforming to other standards, and may be modified in other forms without departing from the technical spirit of this disclosure. Embodiments of this disclosure can be easily modified and applied to other communication systems.

[0049] Additionally, in one embodiment of the present disclosure, it will be understood that singular expressions such as "one" and "the above" include plural expressions unless otherwise clearly indicated.

[0050] Additionally, in one embodiment of the present disclosure, terms including ordinal numbers, such as first, second, etc., may be used to describe various components, but said components are not limited by said terms. Such terms are used solely for the purpose of distinguishing one component from another. For example, without departing from the scope of the present disclosure, the first component may be named the second component, and similarly, the second component may be named the first component.

[0051] Additionally, in one embodiment of the present disclosure, the term "and / or" includes a combination of a plurality of related described items or any of a plurality of related described items.

[0052] Furthermore, the terms used in one embodiment of the present disclosure are used merely to describe specific embodiments and are not intended to limit the present disclosure. The singular expression includes the plural expression unless the context clearly indicates otherwise. In this specification, terms such as “comprising” or “having” are intended to indicate the presence of the features, numbers, steps, actions, components, parts, or combinations thereof described in the specification, and should be understood as not precluding the existence or addition of one or more other features, numbers, steps, actions, components, parts, or combinations thereof.

[0053] Additionally, the terms “associated with” and “associated therewith” and their derivatives used in one embodiment of the present disclosure may mean things such as include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicated with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, etc.

[0054] Additionally, in this disclosure, expressions such as "greater than" or "less than" have been used to determine whether specific conditions are satisfied or fulfilled; however, this is merely for illustrative purposes and does not exclude descriptions of "greater than" or "less than." Conditions described as "greater than" may be replaced with "greater than," conditions described as "less than" with "less than," and conditions described as "greater than and less than" with "greater than and less than."

[0055] Prior to a detailed description of the present disclosure, examples of possible meanings for some terms used in this specification are provided. However, it should be noted that the interpretations provided below are not limited to these examples.

[0056] In the present disclosure, a terminal (or communication terminal) is a subject that communicates with a base station or another terminal and may be referred to as a node, UE (user equipment), NG UE (next generation UE), MS (mobile station), device, or terminal. Additionally, the terminal may include at least one of a smartphone, tablet PC, mobile phone, video phone, e-book reader, desktop PC, laptop PC, netbook computer, PDA, PMP (portable multimedia player), MP3 player, medical device, camera, or wearable device. Additionally, the terminal may include at least one of a television, DVD (digital video disk) player, audio, refrigerator, air conditioner, vacuum cleaner, oven, microwave, washing machine, air purifier, set-top box, home automation control panel, security control panel, media box, game console, electronic dictionary, electronic key, camcorder, or electronic photo frame.In addition, the terminal may include at least one of various medical devices (e.g., various portable medical measuring devices (blood glucose meter, heart rate monitor, blood pressure monitor, or body temperature monitor, etc.), MRA (magnetic resonance angiography), MRI (magnetic resonance imaging), CT (computed tomography), imaging device, or ultrasound device, etc.), navigation device, satellite navigation system (GNSS (global navigation satellite system)), EDR (event data recorder), FDR (flight data recorder), automotive infotainment device, marine electronic equipment (e.g., marine navigation device, gyrocompass, etc.), avionics, security device, vehicle head unit, industrial or household robot, drone, ATM of a financial institution, POS (point of sales) of a store, or Internet of Things device (e.g., light bulb, various sensor, sprinkler device, fire alarm, thermostat, street light, toaster, exercise equipment, hot water tank, heater, boiler, etc.). In addition, the terminal may include various types of multimedia systems capable of performing communication functions. Meanwhile, the present disclosure is not limited to what has been described above, and the terminal may be referred to by terms having the same or similar meaning.

[0057] In addition, in the present disclosure, the base station is an entity that communicates with a terminal and performs resource allocation for the terminal, and may have various forms and may be at least one of a gNode B, eNode B, Node B, BS (Base Station), wireless access unit, base station controller, or a node on a network. Alternatively, it may be referred to as a CU (central unit) or a DU (distributed unit) depending on the separation of functions. Meanwhile, the present disclosure is not limited thereto, and the base station may be referred to by a term having the same or similar meaning.

[0058] In addition, in this disclosure, embodiments may be described using terms used in some communication standards (e.g., 5G (NR (new radio)) or 5G (NR) systems defined by 3GPP (3rd generation partnership project)), but this is merely for illustrative purposes, and embodiments of this disclosure may be applied to other communication systems having similar technical backgrounds or channel types. Furthermore, this disclosure may be applied to other communication systems with some modifications made at the discretion of a person with technical knowledge, without departing significantly from the scope of this disclosure.

[0059] Additionally, in this disclosure, a radio resource control (RRC) message may be referred to as high-level information, high-level message, high-level signal, high-level signaling, high-layer signaling, or high-level signaling, and the disclosure is not limited thereto, but may be referred to by terms having the same or similar meaning.

[0060] Additionally, in the present disclosure, data may be referred to as user data, UP (user plane) data, or application data, or may be referred to by a term having the same or similar meaning as a signal transmitted or received through a DRB (data radio bearer).

[0061] Additionally, in the present disclosure, the direction of data transmitted from a terminal may be referred to as an uplink, and the direction of data transmitted to a terminal may be referred to as a downlink. Accordingly, in the case of uplink transmission, the transmitter may refer to a terminal, and the receiver may refer to a specific network entity of a base station or communication system. Alternatively, in the case of downlink transmission, the transmitter may refer to a specific network entity of a base station or communication system, and the receiver may refer to a terminal.

[0062] The present disclosure relates to a method and apparatus for media-specific network resource allocation and packet processing policy application in a mobile communication system. For example, the present disclosure relates to a method and apparatus for supporting media services including real-time communication services and media streaming services.

[0063] The media service may include one or more media components. The media components may, for example, be a video signal acquired from a camera or an audio signal acquired from a microphone. A media transmitting device may process each media component to form a media stream and transmit it to a media receiving device through a media transport session. The media stream may be considered as a flow of packets in which media data output from a media encoder is encapsulated, and may, for example, be an RTP stream defined as a real-time transport protocol (RTP) packet stream having the same synchronization source (SSRC) field value. The media transport session may include one or more media streams and may be defined, for example, using a 5-tuple (source IP address, destination IP address, source port number, destination port number, protocol).

[0064] The network can allocate network resources in units of service data flows and apply packet processing policies in response to a request from a media service provider. The service data flow refers to a flow of packets that can be identified by a given filtering condition, and the filtering condition may be, for example, the 5-tuple described above. Therefore, it can be assumed that the service data flow may include one or more media transmission sessions.

[0065] Extended Reality (XR) refers to a technology that provides computing-generated content in an environment combining the real and the virtual through interaction between wearable device users and machines. XR creates an extended reality by utilizing Virtual Reality (VR) and Augmented Reality (AR) technologies individually or in combination. XR is expected to be applied in various fields, including education, healthcare, and manufacturing. To realize XR, high-performance computing power and graphics processing capabilities are crucial for displaying large volumes of real-time 3D video. To effectively support XR, display technology must also advance, and 5th generation (5 th Technology for transmitting large amounts of data with ultra-low latency, such as in generation; 5G mobile communication, must be a prerequisite.

[0066] XR content may include various forms of media data, such as graphical objects and haptics, in addition to video and audio. The media data may be encoded using different encoders depending on its format, and the encoder for XR content may include one or more elemental encoders. In this case, the encoded XR media components may be converted into one or more media streams during the packetization process. Additionally, a scene of XR content may include multiple graphical objects, and multiple media streams containing each graphical object may be used for the transmission of XR content.

[0067] The above media stream may have different traffic characteristics depending on the included media, and one or more media streams may have the same traffic characteristics. The traffic characteristics may include, for example, at least one of a maximum transmission bit rate, an allowable transmission delay time, and an allowable packet error rate. Therefore, a network that allocates resources and applies packet processing policies on a service data flow basis cannot provide optimized Quality of Service (QoS) for a service data flow containing two or more media streams with different traffic characteristics. Consequently, in order for a network to process two or more media streams with different traffic characteristics included in a single service data flow according to their respective traffic characteristics, information for identifying each media stream in the service data flow is required. At this time, the information for identifying the media stream and its traffic characteristics may be determined by negotiation between a media transmission device and a media reception device at the time of service initiation. Therefore, a procedure is required to provide the network with media stream identification information and its traffic characteristics based on the result of the negotiation.

[0068] A method of a service control device for supporting a real-time communication service in a mobile communication system according to one embodiment may include: receiving real-time communication service setting information from an application service provider; receiving detailed information of media streams for a real-time communication service from a user terminal or server; and providing network setting information for a real-time communication service to a network.

[0069] According to various embodiments of the present disclosure, services can be smoothly provided using various forms of media, such as XR services, through media stream-based network resource configuration and packet processing.

[0070] FIG. 1 is a 5G system structure for media services in a wireless communication system according to the present disclosure (5 th This is a conceptual diagram illustrating the Generation system (5GS).

[0071] A wireless communication system according to various embodiments of the present disclosure may be, for example, a 5G system (5GS). The 5G system may be composed of a 5G radio access network (NG-RAN: next generation radio access network) and a 5G core network (5GC: 5G core network). The 5GS interworks with existing LTE and may also be connected to non-3GPP radio access technologies such as Wi-Fi. The 5GC is located between the NG-RAN and the external packet data network (PDN: public data network) and can provide various forms of data services, including voice, to users. The control plane components of the 5GC may be considered as virtualized network functions (VNFs), and communication between VNFs may be considered as one VNF providing services to other VNFs through RESTful-based API exchanges. An API-based communication interface between VNFs is called a service-based interface (SBI).

[0072] Referring to FIG. 1, the 5GS may include user equipment (UE) (101), NG-RAN (102) including a base station, user plane function (UPF) device (103), access and mobility management function (AMF) device (111), session management function (SMF) device (112), policy control function (PCF) device (113), network exposure function (NEF) device (114), NF repository function (NRF) device (115), authentication server function (AUSF) device (116), unified data management (UDM) device (117), application function (AF) device (121), and application server (AS) device (122). Of course, 5GS is not limited to the examples described above and may include fewer or more configurations than the configuration shown in FIG. 1. Additionally, each device may be referred to as a network entity, a network function, or a network function apparatus.

[0073] Each network function (NF) of the above 5GS will be described as a “network entity” or “network function” itself. However, a person skilled in the art to which this disclosure pertains (hereinafter, person skilled in the art) will know that an NF and / or an NF device may be implemented in one or more specific servers, and that two or more NFs performing the same operation may be implemented in a single server.

[0074] Additionally, according to the present disclosure, one NF or two or more NFs may, in some cases, be implemented in the form of a network slice. A network slice may be created based on a specific purpose. For example, a network slice may be configured for a group of subscribers to provide the same type of service to a specific group of subscribers, such as a maximum transmission rate and data usage, and a guaranteed minimum transmission rate. In addition, a network slice may be implemented according to various purposes. Since a network slice is obvious to a person skilled in the art, a description is omitted.

[0075] Meanwhile, FIG. 1 illustrates the interfaces between each node in 5GS. For example, the Uu interface may be used between UE (101) and NG-RAN (102), the N2 interface between NG-RAN (102) and AMF (111), the N3 interface between NG-RAN (102) and UPF (103), and the N4 interface between SMF (112) and UPF (103). Additionally, the N6 interface may be used between UPF (103) and AF (121) and AS (122) located in the DN (Data Network). Since the aforementioned interfaces are defined in 3GPP standard specifications, their description is omitted. The interfaces between AF (121) and AS (122) and UE will be described in the media architecture to be described later in FIG. 4.

[0076] FIG. 2 is a diagram illustrating an example of a method for providing quality of service (QoS) per media stream in a wireless communication system according to the present disclosure.

[0077] A wireless communication system according to the present disclosure can configure QoS flows using a media stream as the minimum unit. The QoS flow may refer to a logical minimum unit to which the same packet processing policy is applied in a network.

[0078] Referring to FIG. 2, a media service according to the present disclosure may be provided to a user, for example, through a first service data flow (210) and a second service data flow (220). At this time, the first service data flow (210) may include a first media stream (211) and a second media stream (212), and the second service data flow (220) may include a third media stream (221) and a fourth media stream (222).

[0079] A network device that receives the first service data flow (210) and the second service data flow (220) can use a packet filter (230) to classify the input packets into media stream units and map them back into QoS flows.

[0080] For example, it can be assumed that the first media stream (211) and the third media stream (221) contain voice data, the second media stream (212) contains video data, and the fourth media stream (222) contains text data. In this case, the network may configure the first QoS flow (241) with the first media stream (211) and the third media stream (221) containing voice data, and the second QoS flow (242) and the third QoS flow (243) with the second media stream (212) containing video data and the fourth media stream (222) containing text data, respectively. In this case, a new header may be added to the packet input to the packet filter (230) for packet transmission between the devices constituting the network.

[0081] The above packet filter (230) may conceptually be composed of two packet filters. For example, the first packet filter may perform packet filtering based on information from an IP packet header and a transmission protocol header (for example, UDP (user datagram protocol) or TCP (transmission control protocol)), and the second packet filter may perform packet filtering based on information from an application layer protocol header (for example, RTP header and extension header).

[0082] The above packet filter (230) may be located in the User Plane Function (UPF) device (103) of the 5G system of FIG. 1 described above, and detailed parameters for packet filtering and QoS flow mapping may be obtained through other network functions (NF). For example, a session management function (SMF) device (112) and a policy control function (PCF) device (113) may provide the detailed parameters to the UPF device (103).

[0083] According to the present disclosure, the AF (121) can provide media stream identification information for packet filtering and QoS requirements per media stream to the PCF device (113) directly or through a network exposure function (NEF) device (114).

[0084] The AF (121) according to the present disclosure may be an example of an AF (application function) for supporting media services, such as a Media AF following the conceptualized media transmission structure described later in FIG. 4, or a P-CSCF (proxy call session control function) of the internet protocol multimedia subsystem (IMS) network structure described later in FIG. 6.

[0085] FIG. 3 is a conceptual diagram illustrating an example of a packet structure for transmitting a media stream using the real-time transport protocol (RTP) in a wireless communication system according to the present disclosure.

[0086] Referring to FIG. 3, media data may be encapsulated in an RTP payload (310), and a packet transmitting a media stream may include an RTP payload (310) containing media data, and an RTP header (320), a UDP header (330), and an IP header (340) for processing the media data at a network and media transmission / reception device. The RTP header (320) may include an RTP header extension.

[0087] Referring to FIG. 3, the first 12 octets or 12 bytes of the RTP header (320) are included in every RTP packet, and CSRC identifiers (contributor source identifiers) may be optionally added by an RTP middle box such as a mixer. Each field of the RTP header (320) has the following meaning.

[0088] - version(V): A 2-bit field indicating the RTP version. It has a value of 2 in RTP packet headers compliant with IETF RFC 3550.

[0089] - padding(P): A 1-bit field with a value of 1 if the RTP packet includes padding octets.

[0090] - extension(X): A 1-bit field with a value of 1 if the RTP packet includes an extension header.

[0091] - CSRC count (CC): A 4-bit field indicating the number of CSRC identifiers located after the 12-octet fixed header.

[0092] - marker(M): A 1-bit field whose usage is determined by the RTP profile. For example, when a single video frame is divided into multiple RTP packets for transmission, only the M field value of the last RTP packet among the RTP packets may be set to 1.

[0093] - payload type (PT): A 7-bit field for identifying the RTP payload format. The value of the field can be determined using a static mapping determined by the RTP profile or a dynamic mapping determined by an out-band method using SDP (Session Description Protocol).

[0094] - Sequence number (SN): A 16-bit field that increases by 1 for each RTP packet transmitted. It can be used by the receiver for loss detection and packet order restoration.

[0095] - Timestamp: A 32-bit field that indicates the acquisition or playback time of the data sample included in the RTP packet.

[0096] - SSRC: A 32-bit field representing the identifier of the synchronization source.

[0097] - CSRC: A 32-bit field representing the identifier of the contribution source

[0098] A media service according to one embodiment of the present disclosure may include one or more media transport sessions, and the media transport sessions may be identified by a 5-tuple (source IP address, destination IP address, source port number, destination port number, transport protocol). Accordingly, packets that use the RTP / UDP / IP protocol, such as the packet disclosed in FIG. 3, and have the same source / destination IP address values ​​in the IP header (340) and source / destination port number values ​​in the UDP header (330) may be considered as packets belonging to a single media transport session.

[0099] The above-mentioned media transmission session may include one or more RTP streams. Here, an RTP stream refers collectively to RTP packets having the same SSRC field value within a media transmission session, and each packet may include at least one of media data or data for loss recovery. The data for loss recovery may be, for example, redundant data, FEC (forward error correction) repair data, etc.

[0100] In a wireless communication system according to an embodiment of the present disclosure, the AF (121) may provide information for identifying a media stream and QoS requirements for the media stream to the network. A media stream according to an embodiment of the present disclosure may be, for example, an RTP stream. In this case, the information for identifying the media stream may include at least one of information for identifying a media transmission session to which the RTP stream belongs, an SSRC field value for identifying the RTP stream, and information for identifying a grouped RTP stream. The information for identifying the media transmission session may include a sender / receiver IP address and a UDP port number. The information for identifying the grouped RTP stream may include at least one of media transmission session identification information, a PT field value of an RTP header, and a grouped RTP stream identifier. The grouped RTP stream identifier may be included in an RTP extension header, for example, and the information for identifying the grouped RTP stream may include information for identifying the RTP extension header and extracting the grouped RTP stream identifier from the identified RTP extension header.

[0101] A network in a wireless communication system according to an embodiment of the present disclosure may, by considering media stream identification information provided by AF (121) and QoS requirements for the media stream, generate a QoS flow, and generate a filtering condition for identifying packets belonging to the QoS flow and a policy for processing the filtered packets. A QoS flow according to an embodiment of the present disclosure may include one or more media streams, and the media stream may be, for example, an RTP stream. In this case, the filtering condition may include at least one of information for identifying a media transmission session to which the RTP stream belongs, an SSRC field value for identifying the RTP stream, and information for identifying a grouped RTP stream. The information for identifying the media transmission session may include a sending / receiving IP address and a UDP port number. The information for identifying the grouped RTP stream may include at least one of media transmission session identification information, a PT field value of an RTP header, and a grouped RTP stream identifier. The grouped RTP stream identifier may be included in an RTP extension header, for example, and the information for identifying the grouped RTP stream may include information for identifying the RTP extension header and extracting the grouped RTP stream identifier from the identified RTP extension header.

[0102] FIG. 4 is a conceptual diagram illustrating a generalized media delivery architecture for providing media services in a wireless communication system according to the present disclosure.

[0103] Referring to Fig. 4, the main functional elements of the conceptualized media transmission structure are as follows:

[0104] - AF(121): Application function (AF). An AF that can be used to provide media services may be referred to as Media AF, but this is merely an example and may be expressed in other terms that perform the same function.

[0105] - AS(122): Application server (AS). An AS that can be used for media transmission may be referred to as Media AS, but this is merely an example and may be expressed in other terms that perform the same function.

[0106] - Media client (410): An internal function of the UE (101) for media transmission. As a logical function, it may include the following sub-functions.

[0107] ■ Media session handler (411): An internal function of the UE (101) that communicates with the Media AF (121) to establish and control a media transmission session.

[0108] ■ Media access function (412): An internal function of the UE (101) that communicates with the Media AS (122) for accessing and transmitting media content. The media access function may have detailed functions such as, for example, a media transmission protocol, a media codec, and a metadata processor.

[0109] In FIG. 4, the media session handler (411) and the media access function (412) are shown providing APIs to each other through the M11 interface and to the media-aware application (420) through the M6 ​​and M7 interfaces, respectively. However, depending on the implementation choice, the functions of the element functions may be provided from the media-aware application (420) or other components of the UE (101), in which case the M11, M6, and M7 interfaces may not exist.

[0110] - Media-aware application (420): An application running on the UE (101) that can utilize at least one of the APIs (application program interfaces) provided by the media session handler (411) or the media access function (412) for media transmission.

[0111] Referring to FIG. 4, the components of the conceptualized media transmission structure described above can communicate with each other using the following interface.

[0112] - M1: An interface between the media application provider (480) and the Media AF (121) that can be used for media transmission service provisioning.

[0113] - M2: An interface between a media application provider (480) and a Media AS (122) that can be used to provide media data to the Media AS (122) or to receive it from the Media AS (122).

[0114] - M3: An interface between Media AF (121) and Media AS (122) that can be used for configuration of Media AS (121) or media session processing related to media transmission.

[0115] - M4: An interface between the UE’s media access function (412) and the Media AS (122) that can be used for the media access function (412) to receive media data from the Media AS (122) or to transmit media data to the Media AS (122).

[0116] - M5: An interface between the UE's media session handler (411) and the Media AF (121) that can be used for media session processing related to media transmission.

[0117] - M6: An interface between the media recognition application (420) and the media session handler (411), which can be used to configure the media session handler (411).

[0118] - M7: An interface between the media recognition application (420) and the media access function (412) that can be used to control the media access function (412).

[0119] - M8: An interface between the UE's media recognition application (420) and the media application provider (480) that can be used to control media application service logic.

[0120] - M9: An interface between the first instance and the second instance of Media AF (121) that can be used for interoperability between Media AF instances.

[0121] - M10: An interface between the first instance and the second instance of Media AS (122) that can be used for media relay and processing between Media AS instances.

[0122] - M11: An interface between the media session handler (411) and the media access function (412) that can be used to configure the media session handler (411) or the media access function (412).

[0123] Referring to FIG. 4, the above-described Media AF (121) and Media AS (122) are functions located in the data network (DN) (450) and can communicate with the UE (101) through the N6 interface defined in 5GS. Functions located in the operator's external network (external DN) (e.g., Media AF (121)) can communicate with 5G network functions through the NEF (114) using the N33 interface, and functions located in the operator's trusted network (Trusted DN) (e.g., Media AF (121)) can communicate directly with 5G network functions.

[0124] Referring to FIG. 4, a Media AF (121) located in the operator's trusted network can communicate with a PCF (113) using an N5 interface. Communication between the Media AF (121) and the NEF (114) or PCF (113) may be a network service consumption process using an API provided by the NEF (114) or PCF (113). For example, the Media AF (121) may request traffic processing policy settings, including QoS (quality of service) parameters for media transmission sessions between the UE (101)'s media access function (412) and the Media AS (122) and / or between UEs, by using the Nnef_AFSessionWithQoS service provided by the NEF (114) or the Npcf_PolicyAuthoriztion service provided by the PCF (113). As another example, it may subscribe to a network event notification service and receive notifications when an associated situation occurs on the network. The above event notification can be transmitted directly to the Media AF (121) from the network function associated with the event (e.g., PCF (113) or UPF (103)) or transmitted via the NEF (114).

[0125] Media services according to various embodiments of the present disclosure may include the following three main scenarios.

[0126] - Downlink streaming: The network provides media to the UE, and the UE performs the role of consuming the media.

[0127] - Uplink streaming: The UE provides media to the network, and the network performs the role of consuming the media.

[0128] - Real-time communication (RTC): Mutual exchange of media between RTC endpoints. The said RTC endpoints can be UEs or networks.

[0129] The functions and interfaces of the conceptualized media transmission structure illustrated in FIG. 4 above may provide different functions depending on the scenario described above. For example, the M4 interface described above may be used to transmit and receive media data between the UE (101) and the Media AS (122) in downlink streaming and uplink streaming services, but may be used to transmit and receive media data between the UE (101) and the Media AS (122) or another UE (not shown) for RTC service support in RTC services.

[0130] In a conceptualized media transmission structure according to the present disclosure, the Media AF (121) may receive information regarding a media stream identification method and QoS requirements for the media stream from the media application provider (480). In a conceptualized media transmission structure according to the present disclosure, the Media AF (121) may receive media stream identification information and QoS requirements for the media stream from the UE (101) and / or the Media AS (122). In a conceptualized media transmission structure according to the present disclosure, the Media AF (121) may provide media stream identification information and QoS requirements for the media stream to the PCF device (113) directly or via the NEF device (114) based on the information obtained from the media application provider (480), the UE (101), and / or the Media AS (122).

[0131] FIG. 5 is a diagram illustrating an example of a media service provision procedure in a wireless communication system following a conceptualized media transmission structure according to the present disclosure.

[0132] Referring to FIG. 5, the media awareness application (420) and media client (410) included in the terminal (or UE, 101) may be referred to as the terminal, the terminal and / or media AS (122) included in the RTC endpoint may be referred to as the RTC endpoint, and the PCF (113) / NEF (114), which is a network entity (or function) included in the core network, may be referred to as the network.

[0133] Hereinafter, the application provider (480) in the media service provision procedure may be referred to as a media application provider, the AF (121) that can be used for media service provision may be referred to as Media AF, and the AS (120) that can be used for media transmission may be referred to as Media AS, but these are merely examples of an application provider, AF, and AS, respectively, and may be expressed in other terms that perform the same function.

[0134] 1. Service Provisioning: A media application provider (480) and a Media AF (121) may establish a provisioning session and perform function settings for a media service. The function for the media service may include a dynamic policy invocation, and the provisioning information for setting the dynamic policy invocation function (or setting information for the dynamic policy invocation) may include information regarding a policy template for the dynamic policy invocation. The information regarding the policy template according to an embodiment of the present disclosure may include media stream identification information. The media application provider (480) and / or the Media AF (121) may obtain the information described above as a result of the process of establishing the provisioning session.

[0135] 2. Media AS setting: If necessary, Media AF (121) can set up Media AS (122) based on provisioning information. When setting up Media AS (122), media stream identification information may be provided from Media AF to Media AS (122).

[0136] 3. Service Announcement: A media application provider (480) may deliver service announcement information to a media awareness application (420) running on a user device (UE). The service announcement information may include service access information or a path to obtain service access information. The service access information may include an identifier of a provisioning session associated with the media service and configuration information for a dynamic policy request. For example, the dynamic policy may be a policy applicable to the media service, or a policy applicable to a media transmission session associated with the media service, and this is limited to one example but is not limited thereto. Additionally, for example, the configuration information for the dynamic policy request may include configuration information used by the terminal to request a dynamic policy from the AF in 7. Dynamic policy invocation, which will be described later.

[0137] 4. Start Media Service: The media recognition application (420) may request media processing for the media service selected by the user from the media client (410). At this time, the service connection information or a path to obtain the service connection information may be transmitted to the media client (410).

[0138] 5. Media Session Configuration: If the media client (410) knows a path through which service connection information can be obtained, it can use this path to obtain service connection information.

[0139] 6. Establish Transport Session: A media client (410) and a Media AS (121) (or an RTC terminal) can establish a media transport session for media transmission. In a real-time communication service, the media transport session can be established between the media client (410) and another terminal participating in the real-time communication service. In a downlink streaming service, the process of establishing the media transport session may include a process of obtaining information regarding individual media streams constituting the media service. The information regarding the individual media streams may include at least one of parameters used for media encoding, media transmission characteristics, and URL information for media acquisition. In a real-time communication service, the process of establishing the media transport session may include a process of negotiating connection information (e.g., IP address and port number) and detailed media-related parameters (e.g., an SDP Offer / Answer process) that allows a terminal participating in the real-time communication service and / or a network device to exchange media data. The protocol used in this process may be, for example, SWAP (simple webRTC application protocol), which will be described later. When exchanging media data using the RTP protocol, detailed parameters for media stream filtering may be determined. For example, when media stream filtering is performed using an RTP extension header, the mapping between the URI and ID field values ​​of the RTP extension header to be used can be determined at this stage. As another example, when media stream filtering is performed using the SSRC field values ​​of the RTP header, the SSRC field values ​​per media stream can be determined as SDP parameters at this stage. The SDP according to an embodiment of the present disclosure may include QoS requirements per media stream. The SDP may be used in the negotiation process of the connection information and / or the media-related detailed parameters.

[0140] 7. Dynamic policy invocation: A media client (410) may request a dynamic policy setting to be applied to a media transmission session from a Media AF (121). The dynamic policy setting request may include a provisioning session identifier, an application flow description, and a policy template identifier. The application flow description according to an embodiment of the present disclosure may include information for identifying one or more media streams included in a service data flow and / or QoS requirements per media stream. For example, the policy template identifier may be an identifier corresponding to a policy template selected / determined by the media client (410) among at least one policy template provided during the service provisioning process. Detail parameters of the dynamic policy setting request according to an embodiment of the present disclosure may be determined in the media-related detailed parameter negotiation step of step 6.

[0141] 8. Media traffic policy request: Media AF (121) may request a media transmission traffic processing policy from PCF (113) or NEF (114) (or, said Media AF (121) may send a QoS provision request to the network). A media transmission traffic processing policy (or QoS provision request) according to an embodiment of the present disclosure may include information for identifying one or more media streams included in a service data flow and / or QoS requirements per media stream.

[0142] For example, the network may perform packet filtering and QoS flow mapping as described in FIG. 2 based on information for identifying the one or more media streams and QoS requirements per media stream. For example, the QoS flow mapping may set / create / update dynamic policies to represent QoS flows corresponding to each of the one or more media streams.

[0143] For example, based on the dynamic policy associated with the packet filtering and QoS flow mapping, a response to a request for a media transmission traffic processing policy (or a request for QoS provision) may be transmitted from the network to the AF. The response may include information related to the result of setting the dynamic policy, and the result of setting the dynamic policy may include information about the dynamic policy setting status (e.g., Accepted, Rejected, etc.) and instructions for the dynamic policy (e.g., bit rate, whether QoS is supported per media stream, etc.).

[0144] 9. Confirm QoS Allocation: Media AF (121) may send a response to the media client (410) containing the result of setting the dynamic policy. The response may be a response to 7. Dynamic policy invocation, and the media client (410) may confirm the result of the dynamic policy setting requested from Media AF (121). The policy setting result confirmation message may include information about the dynamic policy setting status (e.g., Accepted, Rejected, etc.) and instructions for the dynamic policy (e.g., bit rate, whether QoS is supported per media stream, etc.).

[0145] 10. Media Contents: A media client (410) may set internal parameters in response to a Media AF (121) and initiate media transmission or reception. For example, the media client may apply the dynamic policy (or the result of setting the dynamic policy) to an established media transmission session to transmit or receive one or more media streams to the RTC end.

[0146] In the example of FIG. 5 described above, the media client (410) requested dynamic policy settings from the Media AF (121), but the Media AS (122) may request dynamic policy settings from the Media AF (121) according to the policy of the mobile communication service provider or the request of the media application provider (480).

[0147] FIG. 6 is a diagram illustrating an IMS (IP (internet protocol) multimedia subsystem) network structure for providing real-time communication services in a wireless communication system according to the present disclosure.

[0148] Referring to FIG. 6, the first UE (101) can establish a real-time communication service session with a remote IMS network or the second UE (680) through an IM CN (IP (internet protocol) multimedia core network) subsystem. The IM CN subsystem may include a P-CSCF (620), an S-CSCF (630), an IMS AS (640), an HSS (650), an IMS AGW (660), and / or an MRF (670), and the components may perform the following functions.

[0149] - P-CSCF (proxy call session control function) (620): The P-CSCF can perform the function of a first contact point for a UE to connect to the IMS. The P-CSCF (620) according to the present disclosure may support a service-based interface (SBI) and thus may be considered an application function (AF) that uses the services provided by the PCF (113) to other virtualized network functions (VNFs). The P-CSCF (620) according to the present disclosure may provide the PCF (113) with information for identifying a media stream and QoS requirements for the media stream based on SDP parameters included in a SIP message and / or the network operator's policy.

[0150] - S-CSCF (serving CSCF) (630): S-CSCF can handle the actual user session state of the network.

[0151] - IMS AS (application server) (640): The IMS AS can provide and execute internet multimedia (IM) value-added services. Additionally, the IMS AS can influence Session Initiation Protocol (SIP) sessions by acting as an agent for services supported by the carrier network.

[0152] - HSS (home subscriber server) (650): The HSS can serve as a database that stores information about users.

[0153] - IMS-AGW(access gateway)(660): The IMS-AGW is located in the media transmission path and can manage network addresses associated with inbound and outbound media streams.

[0154] - MRF (media resource function) (670): The MRF can perform various processing tasks related to media streams. The MRF can be divided into a multimedia resource function controller (MRFC) responsible for control and a multimedia resource function processor (MRFP) responsible for media processing.

[0155] In addition, the IMS network may further include an I-CSCF (interrogating CSCF) (not shown) that performs the function of a contact point for roaming users.

[0156] Meanwhile, referring to FIG. 6, the interface between the components can be represented by the following reference points.

[0157] - Gm: The reference point Gm can support communication between the UE (101) and the IM CN subsystem. For example, the UE can request network registration and session control through the Gm reference point. SIP, which will be described later, can be used for the Gm reference point.

[0158] - Mw: Reference point Mw can support the exchange and transmission of signaling messages between CSCFs (e.g., P-CSCF (620), S-CSCF (630) and / or I-CSCF (not shown)).

[0159] - ISC: The reference point ISC can support the exchange of information necessary for the services provided by the service platform between the S-CSCF (630) and the service platform (e.g., IMS AS (640)).

[0160] - Sh: Reference point Sh can support the exchange of information necessary for the services provided by the service platform between the HSS (650) and the service platform (e.g., IMS AS (640)).

[0161] - Cx: Reference point Cx can support information transfer between the HSS (650) and the CSCF (e.g., P-CSCF (620), S-CSCF (630) and / or I-CSCF (not shown)).

[0162] - Mr' / Cr: Reference point Mr' can support interaction for session control between IMS AS (640) and MRFC (670), and reference point Cr can support interaction for media control between IMS AS (640) and MRFC (670).

[0163] - Iq: Reference point Iq can support the exchange of information necessary for the allocation and release of transport addresses between P-CSCF (620) and IMS AGW (660).

[0164] - Mb: Reference point Mb can support IMS media transfer between IMS components.

[0165] The UE (101) and the IMS network can mutually exchange features and capabilities for service support during the registration or session establishment process.

[0166] The real-time communication service according to the present disclosure may use a signaling protocol to establish sessions and negotiate media parameters between service participants. The signaling protocol may be, for example, SIP or SWAP (simple webRTC application protocol).

[0167] The above-mentioned SWAP is a signaling protocol defined in the 3GPP TS 26.113 standard that communicates via a WebSocket connection between terminals participating in a real-time communication service or between a terminal participating in a real-time communication service and a SWAP server. The above-mentioned SWAP server can manage the state of a session for a real-time communication service and is designed to conform to the state machine of JSEP (JSON Session Establishment Protocol), which is used for session establishment in WebRTC-based real-time communication services. SWAP is a protocol based on a message exchange method and, similar to SIP, can negotiate media parameters using SDPs included in session connection messages, acceptance messages, and session update messages.

[0168] In a conceptualized media transmission structure according to an embodiment of the present disclosure, the Media AS (122) may support a SWAP server function. In this case, the Media AS (122) may provide the Media AF (121) with media stream identification information and QoS requirements for the media stream based on SDP parameters included in the SWAP message and / or the network operator's policy.

[0169] Meanwhile, the aforementioned SIP is an application layer signaling protocol that specifies procedures for intelligent terminals wishing to communicate over the Internet to identify each other, locate their positions, and create, delete, or modify multimedia communication sessions between them. SIP is a request / response structure that controls the creation, modification, and termination of multimedia service sessions—such as Internet-based conferencing, telephone, voicemail, event notifications, and instant messaging—and can be used with both TCP and the User Datagram Protocol (UDP). Furthermore, since SIP uses SIP URLs, similar to email addresses, to distinguish each user, users can receive services without being dependent on their IP addresses. Because SIP is text-based and developed by utilizing many parts of HTTP and SMTP, it is easy to implement and offers the flexibility and scalability to create various services by combining with many other protocols used on the Internet. SIP is a simpler protocol corresponding to ITU-T's H.323. It was proposed as RFC 2543 by the IETF MMUSIC (Multiparty Multimedia Session Control) working group in 1999, and subsequently revised by the separate IETF SIP working group, resulting in the establishment of the RFC 3261 standard in July 2002.

[0170] FIG. 7 is a diagram illustrating a service initiation procedure using SIP (service initiation protocol) in a real-time communication service according to one embodiment of the present disclosure.

[0171] In FIG. 7, it is assumed that a specific UE user participating in a real-time communication service is Alice and a different UE user is Bob, and each terminal is identified as Alice's UE and Bob's UE, respectively. However, this is merely an example arbitrarily set to help explain FIG. 7, and the terms referring to the UEs may be modified into other terms (e.g., first terminal and second terminal).

[0172] Referring to FIG. 7, user Alice can use her own UE (SIP UE) (710) to talk to Bob's UE (SIP UE) (740), and to establish a call session, the following communication procedure can be performed between Alice's proxy server (SIP proxy server) (720) and user Bob's proxy server (SIP proxy server) (730).

[0173] - Step 751: Alice's UE (710) sends a SIP INVITE request to Alice's proxy server (720) that includes a session description protocol (SDP) offer, which will be described later. The SIP INVITE may include the SIP URI of the caller (Alice), the SIP URI of the recipient (Bob), and information for establishing a call session.

[0174] - Step 752: Alice's proxy server (720) receives the SIP INVITE request sent in Step 751 and sends a 100 Trying response to Alice's UE (710). The 100 Trying response indicates that the SIP INVITE has been received by Alice's proxy server (720) and that Alice's proxy server (720) is in action to deliver the SIP INVITE request to the recipient (Bob).

[0175] - Step 753: Alice's proxy server (720) checks the network address of Bob's proxy server (730) using a method such as DNS (Domain Name Service) and transmits the SIP INVITE to Bob's proxy server (730). At this time, Alice's proxy server (720) may add (or include) the network address of Alice's proxy server (720) to the Via header field of the SIP INVITE to be transmitted to Bob's proxy server (730).

[0176] - Step 754: Bob's proxy server (730) receives the SIP INVITE and sends 100 Trying to Alice's proxy server (720). The 100 Trying response indicates that Bob's proxy server (730) has received the SIP INVITE and that Bob's proxy server (730) is processing the SIP INVITE request.

[0177] - Step 755: Bob's proxy server (730) checks the network address of Bob's UE (740) using a database, etc., and sends a SIP INVITE to Bob's UE (740). At this time, Bob's proxy server (730) may add (or include) the network address of Bob's proxy server (730) to the Via header field of the SIP INVITE to be sent to Bob's UE (740).

[0178] - Step 756: Bob's UE (740) receives the INVITE and notifies Bob via sound, vibration, screen, etc. that a call request has been received from Alice. Additionally, Bob's UE (740) notifies Bob's proxy server (730) via an 180 Ringing response that the operation is in progress. At this time, the network address of Bob's proxy server (730) can be identified by the information added (or included) to the Via header field in Step 755.

[0179] - Step 757: Bob's proxy server (730) forwards the received 180 Ringing response to Alice's proxy server (720). At this time, the network address of Alice's proxy server (730) can be identified by the information added to the Via header field in Step 753.

[0180] - Step 758: Alice's proxy server (720) forwards the received 180 Ringing response to Alice's UE (710). Alice's UE (710), having received the 180 Ringing response, can notify Alice of this through a ring-back tone.

[0181] - Step 759: When Bob decides to accept the call, Bob's UE (740) indicates that the call has been answered via a 200 OK response containing an SDF Answer, which will be described later in FIG. 8. Consequently, the SDP is transmitted from Alice's UE (710) to Bob's UE (740) and back from Bob's UE (740) to Alice's UE (710), which corresponds to a media capability negotiation using the SDP offer / answer, which will be described later in FIG. 8. The 200 OK response may include a network address in the Contact header field that can communicate directly with Bob's UE (740).

[0182] - Step 760: Bob's proxy server (730) forwards the received 200 OK response to Alice's proxy server (720). At this time, the network address of Alice's proxy server (730) can be identified by the information added to the Via header field in Step 753.

[0183] - Step 761: Alice's proxy server (720) forwards the received 200 OK response to Alice's UE (710). Upon receiving the 200 OK response, Alice's UE (710) can stop the ringtone and notify Alice that the call has been answered.

[0184] - Step 762: Alice's UE (710) sends an ACK message to Bob's UE (740) indicating that the final response (200 OK) has been received. The ACK message can be sent to Bob's UE (740) without passing through Alice's proxy server (720) and Bob's proxy server (730) by using the network address of Bob's UE (740) included in the Contact header field in Step 759.

[0185] - Step 763: A handshake procedure consisting of INVITE / 200 / ACK is completed and a multimedia session begins. During the media session, Alice or Bob may change the characteristics of the multimedia session, which may be performed by a re-INVITE / 200 / ACK handshake including an SDP offer that reflects the changed characteristics of the multimedia session.

[0186] - Step 764: If Bob ends the call first, Bob's UE (740) sends a BYE message to Alice's UE (710).

[0187] - Step 765: Alice's UE (710), having received the BYE message, sends a 200 OK response indicating that it has received the BYE message, and the call session is terminated.

[0188] In the aforementioned step 751, the SIP INVITE request transmitted by Alice's UE (710) may include feature and capability information for service support. In the aforementioned step 752, Alice's proxy server (720) determines whether the requested features and capabilities are supported based on Alice's subscription information and the network provider's policy, and depending on the result of the determination, deletes some features and capabilities and transmits them to Bob's proxy server (730), or refuses to establish a call session. In step 754, Bob's proxy server (730) also determines whether the requested features and capabilities are supported based on Bob's subscription information and the network provider's policy regarding the SIP INVITE request received from Alice's proxy server (720), and depending on the result of the determination, deletes some features and capabilities and transmits them to Bob's UE (740), or refuses to establish a call session.

[0189] Below, an example of a Session Description Protocol (SDP) included in a SIP message is described. For instance, the SDP included in the SWAP message of Step 6 in FIG. 5 and / or the SIP messages of Step 751 (i.e., SIP INVITE request) and Step 759 (i.e., 200 OK response) in FIG. 7 will be described. The SDP is an ASCII sentence-based protocol for describing multimedia sessions and related schedule information. The purpose of the SDP is to convey information regarding the media streams of a multimedia session so that one can join the session; a multimedia session is defined as a set of media streams over a duration, and the duration of the session does not need to be continuous. Multicast-based sessions on the Internet fundamentally serve two purposes: a means of announcing the existence and time of a session and a means of conveying information about joining the session; in a unicast environment, the latter is the purpose. The content of the SDP information may include the session name and purpose, session duration, session configuration media, media reception information, etc.

[0190] An SDP description is in the form of a document and may include a session-level section and zero or more subsequent media descriptions. An example of the SDP description is shown in [Table 1] below.

[0191]

[0192] In the example shown in [Table 1] above, the SDP description includes a session-level section containing "v=" line, "o=" line, "s=" line, "c=" line, and "t=" line, and two media descriptions ("m=" line). The meaning of each line in the SDP description is as follows.

[0193] - "v=" row (version-field): A row indicating the version of the SDP. For example, the "v=" row in [Table 1] above means that the SDP version is 0.

[0194] - "o=" row (origin-field): A row representing the originator. The "o=" row may include, in order, the Username, session identifier (sess-id), session version (sess-version), network type (nettype), network address type (addtype), and the network address of the session initiator (unicast-address). For example, the "o=" row of [Table 1] above means that alice initiates a session with identifier 2819384758 and version 2819384758 at IP4 address 198.51.100.1 in the IN (internet) network.

[0195] - "s=" row (session-name-field): A row representing the name of a session consisting of characters. For example, the "s=" row in [Table 1] above means that the name of the session is "Call to Bob".

[0196] - "c="row (connection-field): Information required to establish a network connection. The "c="row may include, in order, the network type (nettype), network address type (addtype), and network address (connection-address). The "c="row in [Table 1] above means to establish a network connection to the IP4 address 198.51.100.1 of the IN (internet) network. When establishing a media transmission session to a different IP address, the "c="row above may be configured on a media description ("m="row) basis.

[0197] - "t=" row (time-field): A row indicating the start and end times of a session. For example, the "t=" row in [Table 1] above represents a permanent session.

[0198] - "m="row (media-field): A single media description begins with "m="row and ends at the end of the next "m="row or SDP description, and may include additional attributes. "m="row may include, in order, media type, transport port number, transport protocol identifier, and media format description. In the example shown in [Table 1] above, the "a=rtpmap" attribute provides a mapping between the RTP payload format (the PL field value of the RTP packet header) and the media format. The RTP payload format may be a value registered with IANA or a dynamically assigned value. The media format may include codec identifiers such as AMR, H264, etc., and may further include a clock rate or the number of audio channels. For example, the first media description (first "m=" row) of [Table 1] above means to transmit and / or receive audio information using the AMR codec via the RTP / AVP protocol through port 49170, and the second media description (second "m=" row) means to transmit video information using the H.264 codec via the RTP / AVP protocol through port 51372. The RTP / AVP above refers to the Audio Video Profile of RTP (real-time transport protocol).

[0199] In order to provide a service (e.g., a real-time communication service) in a wireless communication system according to the present disclosure, there must be an agreement between user UEs participating in the service regarding parameters that constitute a media transmission session constituting the service. In order to provide a service (e.g., a real-time communication service), the wireless communication system according to the present disclosure may perform an agreement regarding parameters constituting the media transmission session through SDP negotiation. Hereinafter, various embodiments of the present disclosure are described assuming that the service provided by the wireless communication system is a real-time communication service, but are not limited thereto.

[0200] FIG. 8 is a diagram illustrating the session description protocol (SDP) negotiation procedure of a real-time communication service in a wireless communication system according to one embodiment of the present disclosure.

[0201] It should be noted that in FIG. 8, only the SDP exchange (or negotiation) procedure is considered, and the procedure for initiating a real-time communication service using signaling protocols including the aforementioned SIP, SWAP, etc. is not included. Additionally, in FIG. 8, it is assumed that the user of a specific UE is Alice and the user of another UE is Bob, and each terminal is depicted as Alice's UE and Bob's UE, respectively; however, this is merely an example arbitrarily set to help explain FIG. 7 and can be modified into other terms such as the first terminal and the second terminal.

[0202] Referring to FIG. 8, in a wireless communication system according to the present disclosure, a real-time communication service can perform media parameter negotiation using SDP in the following procedure.

[0203] - Step 801: Alice's UE (710) sends an SDP Offer to Bob's UE (740). [Table 2] below shows an example of the SDP Offer. Referring to [Table 2] below, Alice proposes media descriptions for the following three media streams.

[0204] ■ Voice Stream 1: UDP port 49170, PCMU codec (payload type 0)

[0205] ■ Video Stream 1: UDP port 51372, H.261 codec (payload type 31)

[0206] ■ Video Stream 2: UDP port 53000, MPV codec (payload type 32)

[0207]

[0208] - Step 802: Bob's UE (740) generates an Answer (SDP Answer) to the SDP proposal and sends it to Alice's UE (710). [Table 3] below shows an example of the SDP Answer. Referring to [Table 3] below, Bob can provide an Answer for the following three media streams.

[0209] ■ Voice Stream 1: UDP port 49920, PCMU codec (payload type 0)

[0210] ■ Video Stream 1: Do not want to open the video stream using the H.261 codec (Set UDP port to 0 and undefined media properties ("a=" line))

[0211] ■ Video Stream 2: UDP port 53000, MPV codec (payload type 32)

[0212]

[0213] - Step 803: During the call session, Bob's UE (740) decides to change the UDP port number for receiving voice from 49920 to 65422 and add a separate receive-only voice stream for receiving events. Bob's UE (740) generates an SDP Offer reflecting the above and sends it to Alice's UE (710). [Table 4] below shows an example of the SDP Offer. Referring to [Table 4] below, Bob proposes media descriptions for the following four media streams.

[0214] ■ Voice Stream 1: Change UDP port 49920 to 65422, PCMU codec (payload type 0)

[0215] ■ Video Stream 1: Do not want to open the video stream using the H.261 codec (Set UDP port to 0 and undefined media properties ("a=" line))

[0216] ■ Video Stream 2: UDP port 53000, MPV codec (payload type 32)

[0217] ■ Voice Stream 2: UDP port 51434, DTMF (Dual Tone Multiple Frequency) event (payload type 110), receive only (recvonly)

[0218]

[0219] - Step 804: Alice's UE (710) generates an Answer to the above SDP proposal and sends it to Bob's UE (740). [Table 5] below shows an example of the above SDP Answer. Referring to [Table 5] below, Alice provides an Answer for the following four media streams.

[0220] ■ Voice Stream 1: UDP port 49170, PCMU codec (payload type 0)

[0221] ■ Video Stream 1: Video stream using H.261 codec disabled (UDP port set to 0)

[0222] ■ Video Stream 2: UDP port 53000, MPV codec (payload type 32)

[0223] ■ Voice Stream 2: UDP port 53122, DTMF Event (Payload Type 110), sendonly

[0224]

[0225] An SDP according to the present disclosure may include a media stream group attribute representing a media stream group. The media stream group attribute may include a media stream group identifier and one or more media stream identification information. The media stream group identifier is a value that can uniquely identify a media stream within an associated SDP document, and may be, for example, a string or a number. The media stream identification information may include an identifier of the media description ("m="line") to which the RTP stream belongs and / or an RTP stream identifier. The media description ("m="line") identifier may be the value of the "mid" attribute belonging to the associated media description. The RTP stream identifier may be the value of the "ssrc" attribute belonging to the associated media description. <ssrc-id>It can be a value. The above <ssrc-id>The value can be an integer between 0 and (2^32)-1, for example, and is the value of the SSRC header field of the RTP packet in the media transmission session described by the associated media description. <ssrc-id>It can refer to an RTP stream identical to the value.

[0226] An SDP according to the present disclosure may include a QoS information attribute (QoS attribute) indicating QoS requirements per media stream and / or media stream group. The QoS information attribute may include QoS requirements and media stream identification information to which the QoS requirements apply. The QoS requirements may include, for example, at least one of the following QoS requirement parameters:

[0227] - Maximum desired bandwidth: Can be defined as the highest bandwidth available for normal operation. May correspond to the maximum bit rate of the codec used for media stream encoding.

[0228] - Minimum desired bandwidth: Can be defined as the lowest bandwidth available in normal or degraded operating conditions. It may correspond to or be higher than the minimum bit rate of the codec used for media stream encoding.

[0229] - Maximum supported bandwidth: The highest bandwidth available for use in a session, which can be set considering redundancy.

[0230] - Minimum supported bandwidth: Can be defined as the lowest bandwidth available for use in exceptional operating conditions. If network conditions do not meet the minimum supported bandwidth, the service may be suspended.

[0231] - Maximum requested bandwidth: Can be defined as the maximum value of bandwidth required for service support

[0232] - Minimum requested bandwidth: Can be defined as the minimum value of bandwidth required for service support

[0233] - Maximum packet loss rate: Can be defined as the maximum packet loss rate for the smooth provision of services. The packet loss rate can be defined as the ratio of packets lost in the network to the total packets transmitted by the media transmission device.

[0234] - Maximum packet error rate: Can be defined as the maximum packet error rate for the smooth provision of the service. The packet error rate can be defined as the value obtained by subtracting the ratio of packets received without errors by the media receiving device to the total packets transmitted by the media transmitting device from 1.

[0235] - Packet latency: This may be defined as the time from when a packet transmitted by a media transmission device is received by a media reception device. Alternatively, it may be the time taken for a packet transmitted by a media transmission device to reach the end of a wireless network to which the media transmission device is connected, or the time taken for a packet that has arrived at the end of a wireless network to reach a media reception device connected to the wireless network.

[0236] The exemplified QoS requirement parameters may have common or different values ​​for the uplink and downlink. Additionally, bandwidth-related parameters, maximum packet loss rate, and maximum packet error rate may be values ​​based on the wireless network segment to which the media transmitting or receiving device is connected, and / or values ​​based on the end-to-end network segment between the media transmitting device and the media receiving device.

[0237] The above media stream identification information may include one or more media stream identification information and / or media stream group identifiers. The above media stream identification information may include an identifier of the media description ("m="line") to which the RTP stream belongs and / or an RTP stream identifier. The media description ("m="line") identifier may be the value of the "mid" attribute belonging to the associated media description. The RTP stream identifier is the value of the "ssrc" attribute belonging to the associated media description. <ssrc-id>It can be a value. The above <ssrc-id>The value can be an integer between 0 and (2^32)-1, for example, and is the value of the SSRC header field of the RTP packet in the media transmission session described by the associated media description. <ssrc-id>It can refer to an RTP stream identical to the value.

[0238] In a conceptualized media transmission structure according to the present disclosure, a Media AS and / or UE including a signaling server function may identify QoS requirements per media stream from the result of a media parameter negotiation process and, based thereon, provide media stream identification information and QoS requirements per media stream to a Media AF. The Media AF may request QoS provision from a network based on the media stream identification information and QoS requirements per media stream received from the Media AS and / or UE. The QoS provision request made by the Media AF to the network may include media stream identification information and QoS requirements per media stream. The QoS requirements per media stream may be provided on an individual media stream basis or on a media stream group basis, and if QoS requirements are provided on a media stream group basis, the media stream identification information may further include information for identifying said media stream group.

[0239] The above media parameter negotiation process may be an SDP Offer / Answer process as shown in FIG. 8, for example. In the SDP Offer / Answer process according to the present disclosure, the SDP may include a QoS requirement attribute, and may further include a media stream group attribute if the QoS requirement attribute describes a QoS requirement for a media stream group.

[0240] In an IMS network according to the present disclosure, a P-CSCF may identify QoS requirements per media stream from the result of the negotiation process (e.g., the SDP Offer / Answer process) and / or from an intermediate SDP, and request the network to provide QoS based thereon. The request for QoS provision made by the P-CSCF to the network may include media stream identification information and QoS requirements per media stream. The QoS requirements per media stream may be provided on an individual media stream basis or on a media stream group basis, and if QoS requirements are provided on a media stream group basis, the media stream identification information may further include information for identifying the media stream group.

[0241] In a wireless network according to the present disclosure, a Media AF and / or P-CSCF may request QoS provision from a PCF device (113) directly or through an NEF device (114).

[0242] In a media service according to the present disclosure, a media stream may be modified, added, or deleted after the service has started. If a change in media parameters and / or QoS requirements occurs due to the modification, addition, or deletion of the media stream, the media negotiation process and / or QoS request procedure described above may be restarted. That is, even if the media negotiation process does not occur due to the modification, addition, or deletion of the media stream, the real-time communication service end according to the present disclosure may notify the network of changes in the SSRC list belonging to the RTP stream group caused by the modified, added, or deleted RTP stream through a QoS update request. The network according to the present disclosure may update the parameters of the packet filter based on the received QoS update request.

[0243] Hereinafter, embodiments of the present disclosure are described according to various methods by which a media service provider configures media services. Subsequent embodiments describe QoS flow mapping and QoS requirements per QoS flow in the wireless network connected to the UE, based on the media parameters of the SDP Offer, under the assumption that the SDP Offer / Answer process has been completed according to the SDP Offer proposed by the UE.

[0244] FIG. 9 is a diagram illustrating an SDP including QoS requirements per media transmission session according to one embodiment of the present disclosure.

[0245] The QoS information attributes of the SDP according to the present disclosure may include QoS requirements per media transmission session.

[0246] Referring to FIG. 9, the SDP of a real-time communication service according to the present disclosure may include a first media description (910) describing voice information of a media transmission session with an IP address of 198.51.100.1 and a port number of 10000, and a second media description (920) describing video information of a media transmission session with an IP address of 198.51.100.1 and a port number of 10002. The first media description (910) may include an a=qos-info attribute (911) indicating the transmission and reception QoS requirements of the voice information, and the second media description (920) may each include a=qos-info attributes indicating the bandwidth of the transmitted video (921), the bandwidth of the received video (922), and the QoS requirements (923) of the transmitted and received video.

[0247] The above a=qos-info attribute (911, 921, 922, 923) can be expressed as an example in ABNF (augmented backus-naur form) as shown in Table 6 below.

[0248]

[0249] In relation to Table 6 above, the above <stream-id>In parameters, "*" is the subsequent <qos-paramter>It can indicate that it corresponds to all RTP streams of the associated media description. The above <direction>In the parameters, "send" is the subsequent <qos-parameter>It can indicate that it is a value associated with the media to be transmitted (a value associated with uplink traffic), and "recv" is the subsequent <qos-parameter>It can indicate that it is a value associated with the media to be received (a value associated with downlink traffic), and "sendrecv" is the subsequent <qos-parameter>It can indicate that it is a value associated with all media to be transmitted and received (a value associated with both uplink and downlink traffic).

[0250] A PCF device (113) of a network according to the present disclosure, for example 5GS, can map media transmission sessions described by the SDP of FIG. 9 into QoS flows as follows:

[0251] - 1st QoS Flow: Transmit / Receive IP = 198.51.100.1, Transmit / Receive Port Number = 10000, Media Type = Audio, Bidirectional Max Flow Bitrate = 29, Bidirectional Packet Loss Rate = 0.01%, Bidirectional Packet Latency = 100 ms

[0252] - 2nd QoS Flow: Transmit / Receive IP = 198.51.100.1, Transmit / Receive Port Number = 10002, Media Type = Video, Uplink Max Flow Bitrate = 1000 kbps, Downlink Max Flow Bitrate = 2000 kbps, Bidirectional Packet Loss Rate = 0.001%, Bidirectional Packet Latency = 150 ms

[0253] In the media service according to the present disclosure, media streams may be changed, added, or deleted after the service begins.

[0254] Referring to FIG. 9, the real-time communication service according to the present disclosure may change the codec of a voice stream after the service has started. For example, the real-time communication service according to the present disclosure may change the codec of a voice stream from an AMR codec to an EVS codec after the service has started. At this time, the real-time communication service end proposing the change of the voice stream codec may add information about the EVS codec to the first media description (910) and initiate an SDP Answer / Offer procedure. If there is no change in QoS requirements due to the codec change, the contents of the "a=qos-info" attribute (911) may remain unchanged, and the real-time communication service end may not update the QoS provision request after the SDP Answer / Offer process.

[0255] As another example, the real-time communication service according to the present disclosure may add a video stream after the service has started. Referring to FIG. 9, if the added video stream does not use the H.264 codec described in the second media description (920), an SDP Answer / Offer procedure is required for the use of an additional payload type. At this time, if the existing allocated bandwidth of 2000 kbps is shared between the existing video stream and the added video stream, and the added video stream does not have additional QoS requirements, the contents of the "a=qos-info" attributes (921, 922, 923) may remain unchanged, and the real-time communication service end may not update the QoS provision request after the SDP Answer / Offer process. On the other hand, if the added video stream has additional QoS requirements, such as requiring additional bandwidth, an SDP Offer / Answer process including "a=qos-info" attribute values ​​reflecting this may be initiated, and the real-time communication service end may update the QoS provision request as a result.

[0256] FIG. 10 is a diagram illustrating an SDP including QoS requirements per media description according to one embodiment of the present disclosure.

[0257] The QoS information attribute of the SDP according to the present disclosure may include QoS requirements per media description. For example, referring to FIG. 10, the SDP may be configured with a BUNDLE group with an a=group attribute (1010), wherein the BUNDLE group may be configured to include a first media description (1020) with a mid attribute value of foo (1021) and a second media description (1030) with a mid attribute value of bar (1031). This may mean that both an RTP stream containing voice information described in the first media description (1020) and an RTP stream containing video information described in the second media description (1030) are transmitted in a media transmission session with an IP address of 198.51.100.1 and a port number of 10000. Additionally, the a=rtcp-mux attribute (1022, 1032) included in the first media description (1020) and the second media description (1030) may indicate that RTCP (real-time transport control protocol) packets are also multiplexed and transmitted into the media transmission session. An RTP extension header containing a mid value may be used as a method to identify the RTP stream belonging to each media description in the multiplexed media transmission session, and the SDP of FIG. 10 may include the a=extmap attribute (1024, 1036) to negotiate the use of the RTP extension header.

[0258] Additionally, the first media description (1020) may include an a=qos-info attribute (1023) indicating the transmission and reception QoS requirements of voice information, and the second media description (1030) may include a=qos-info attributes indicating the bandwidth of the transmitted video (1033), the bandwidth of the received video (1034), and the QoS requirements (1035) of the transmitted and received video, respectively.

[0259] A PCF device (113) of a network according to the present disclosure, for example 5GS, can map a media transmission session described by the SDP of FIG. 10 into a single QoS flow as follows:

[0260] - 1st QoS Flow: Transmit / Receive IP = 198.51.100.1, Transmit / Receive Port Number = 10000, Transport Protocol = RTP&RTCP, Media Type = Audio & Video, Uplink Max Flow Bitrate = 1081 kbps, Downlink Max Flow Bitrate = 2131 kbps, Bidirectional Packet Loss Rate = 0.001%, Bidirectional Packet Latency = 150 ms

[0261] The above-mentioned uplink maximum flow bitrate and downlink maximum flow bitrate are values ​​that take into account the bandwidth-related a=qos-info attribute values ​​(1023, 1033, 1034) of the first media description (1020) and the second media description, and RTCP bandwidth, for example, 5% of the media bandwidth. The above-mentioned RTCP bandwidth may be set to 5% of the media bandwidth if no separate signaling exists, and may follow that value if there is a separate signaling indicating the RTP bitrate (for example, the a=RR or a=RS attribute value of SDP). The above-mentioned bidirectional packet loss rate and bidirectional packet delay time may be set according to the smaller value among the related a=qos-info attribute values ​​(1024, 1035).

[0262] A PCF device (113) of a network according to the present disclosure, for example 5GS, can map a media transmission session described by the SDP of FIG. 10 into a first QoS flow for an RTP stream and a second QoS flow for an RTCP stream as follows:

[0263] - 1st QoS Flow: Transmit / Receive IP = 198.51.100.1, Transmit / Receive Port Number = 10000, Transport Protocol = RTP, Media Type = Audio & Video, Uplink Max Flow Bitrate = 1029 kbps, Downlink Max Flow Bitrate = 2029 kbps, Bidirectional Packet Loss Rate = 0.001%, Bidirectional Packet Latency = 100 ms

[0264] - 2nd QoS Flow: Transmit / Receive IP = 198.51.100.1, Transmit / Receive Port Number = 10000, Transport Protocol = RTCP, Uplink Max Flow Bitrate = 81 kbps, Downlink Max Flow Bitrate = 81 kbps, Bidirectional Packet Loss Rate = 0.001%, Bidirectional Packet Latency = 100 ms

[0265] A PCF device (113) of a network according to the present disclosure, for example 5GS, can map media transmission sessions described by the SDP of FIG. 10 by dividing them into a first QoS flow for voice data and a second QoS flow for video data as follows:

[0266] - 1st QoS Flow: Transmit / Receive IP = 198.51.100.1, Transmit / Receive Port Number = 10000, Transport Protocol = RTP&RTCP, Media Type = Audio, RTP Extended Header Identifier for Media Stream Identification = 1, RTP Extended Header mid value for Media Stream Identification = foo, Bidirectional Max Flow Bitrate = 31, Bidirectional Packet Loss Rate = 0.01%, Bidirectional Packet Latency = 100 ms

[0267] - 2nd QoS Flow: Transmit / Receive IP = 198.51.100.1, Transmit / Receive Port Number = 10000, Transport Protocol = RTP&RTCP, Media Type = Video, RTP Extended Header Identifier for Media Stream Identification = 1, RTP Extended Header mid value for Media Stream Identification = bar, Uplink Max Flow Bitrate = 1050 kbps, Downlink Max Flow Bitrate = 2010 kbps, Bidirectional Packet Loss Rate = 0.001%, Bidirectional Packet Latency = 150 ms

[0268] A packet filter for identifying RTCP packets belonging to the first QoS flow and the second QoS flow may perform filtering using the SSRC value belonging to each media description. To this end, in a real-time communication service according to the present disclosure, an AF may provide the network with the SSRC value(s) corresponding to the RTP stream(s) belonging to the media description identified by the mid attribute value for packet filter configuration. A real-time communication service end according to the present disclosure may collect, on a media transmission session basis, a list of SSRC values ​​used by the real-time communication service end for RTP streams or RTCP reporting and a list of SSRC values ​​used by other real-time communication service end(s) for RTP streams or RTCP reporting, and notify the AF. The real-time communication service end may be a user terminal or an AS.

[0269] A PCF device (113) of a network according to the present disclosure, for example 5GS, can map media transmission sessions described by the SDP of FIG. 10 into a first QoS flow for voice data, a second QoS flow for video data, and a third QoS flow for RTCP data as follows:

[0270] - 1st QoS Flow: Transmit / Receive IP = 198.51.100.1, Transmit / Receive Port Number = 10000, Transport Protocol = RTP, Media Type = Audio, RTP Extended Header Identifier for Media Stream Identification = 1, RTP Extended Header mid value for Media Stream Identification = foo, Bidirectional Max Flow Bitrate = 29, Bidirectional Packet Loss Rate = 0.01%, Bidirectional Packet Latency = 100 ms

[0271] - 2nd QoS Flow: Transmit / Receive IP = 198.51.100.1, Transmit / Receive Port Number = 10000, Transport Protocol = RTP, Media Type = Video, RTP Extended Header Identifier for Media Stream Identification = 1, Mid Value of RTP Extended Header for Media Stream Identification = bar, Uplink Max Flow Bitrate = 1000 kbps, Downlink Max Flow Bitrate = 2000 kbps, Bidirectional Packet Loss Rate = 0.001%, Bidirectional Packet Latency = 150 ms

[0272] - 3rd QoS Flow: Source / Receive IP = 198.51.100.1, Source / Receive Port Number = 10000, Transport Protocol = RTCP, Uplink Max Flow Bitrate = 81 kbps, Downlink Max Flow Bitrate = 102 kbps, Bidirectional Packet Loss Rate = 0.001%, Bidirectional Packet Latency = 100 ms

[0273] FIG. 11 is a diagram illustrating an SDP including QoS requirements per RTP stream and / or RTP stream group according to one embodiment of the present disclosure.

[0274] The QoS information attributes of an SDP according to the present disclosure may include QoS requirements per RTP stream and / or RTP stream group.

[0275] Referring to FIG. 11, the SDP of a real-time communication service according to the present disclosure may include a first media description (1110) describing video information of a media transmission session with an IP address of 198.51.100.1 and a port number of 10002. The first media description (1110) may include a=ssrc attributes (1120, 1121, 1122) that provide attributes for an RTP stream. The a=ssrc attributes may include an ssrc value representing an RTP stream and attributes to be applied to the RTP stream identified by the ssrc value. For example, the a=ssrc attributes (1120, 1121, 1122) included in the SDP of FIG. 11 indicate that RTP streams with SSRC values ​​of 342, 521, or 873 belong to the same RTP endpoint. The above RTP terminal may be, for example, a device owned by a user (UE) defined by a cname (Canonical name). The three video RTP streams transmitted and received at the above RTP terminal may, for example, be videos acquired from three cameras. For example, the three cameras may each be a first camera that acquires video of the entire conference room and second and third cameras assigned to each of the two speakers. In this case, the real-time communication service may transmit the video acquired from the first camera (e.g., main video) in high quality, and the video acquired from the second and third cameras (e.g., thumbnail video) in low quality. Additionally, the video acquired from the second and third cameras may be configured to transmit by dividing the given bandwidth according to the scene (e.g., which speaker is speaking).

[0276] Referring to FIG. 11, the SDP of a real-time communication service according to the present disclosure may include an a=qos-info attribute (1140) representing the QoS requirements of an RTP stream and an a=qos-group-info attribute (1150) representing the QoS requirements of an RTP stream group. The a=qos-group-info attribute (1150) may include an RTP stream group identifier and QoS requirements to be applied to an RTP stream that can be identified by the RTP group identifier. The RTP stream group identifier may be defined by an a=ssrc-qos-group attribute (1130).

[0277] The above a=ssrc-qos-group attribute (1130) can be represented as ABNF in Table 7 below, for example.

[0278]

[0279] In relation to Table 7, the ssrc-group-id may have any string (token) as its value, and the stream-id may have one or more SSRC values ​​separated by ",".

[0280] The above a=qos-group-info attribute (1150) can be represented as ABNF in Table 8 below, for example.

[0281]

[0282] With reference to Table 8, the above ssrc-group-id is to follow <qos-parameter>It may be an identifier for the RTP stream group to which the parameter is to be applied. The above <direction>In the parameters, "send" is the subsequent <qos-parameter>It can indicate that it is a value associated with the media to be transmitted (a value associated with uplink traffic), and "recv" is the subsequent <qos-parameter>It can indicate that it is a value associated with the media to be received (a value associated with downlink traffic), and "sendrecv" is the subsequent <qos-parameter>It can indicate that it is a value associated with all media to be transmitted and received (a value associated with both uplink and downlink traffic).

[0283] A PCF device (113) of a network according to the present disclosure, for example 5GS, can map media transmission sessions described by the SDP of FIG. 11 into a first QoS flow for a video RTP stream with an SSRC value of 342 and a second QoS flow for video RTP streams with SSRC values ​​of 521 and 873 as follows:

[0284] - 1st QoS Flow: Transmit / Receive IP = 198.51.100.1, Transmit / Receive Port Number = 10002, Transport Protocol = RTP, Media Type = Video, RTP Stream Identifier (SSRC) = 342, Bidirectional Max Flow Bitrate = 1500 kbps, Bidirectional Packet Loss Rate = 0.01%, Bidirectional Packet Latency = 150 ms

[0285] - 2nd QoS Flow: Transmit / Receive IP = 198.51.100.1, Transmit / Receive Port Number = 10002, Transport Protocol = RTP, Media Type = Video, RTP Stream Identifier (SSRC) = 521&873, Bidirectional Max Flow Bitrate = 500 kbps, Bidirectional Packet Loss Rate = 0.015%, Bidirectional Packet Latency = 100 ms

[0286] In a media service according to the present disclosure, media streams may be modified, added, or deleted after the service has started. For example, a real-time communication service according to the present disclosure may add a video stream after the service has started. In this case, if the added video stream uses the same media parameters as existing video streams and does not affect existing QoS requirements, the video stream may be added without an SDP Offer / Answer process. In this case, a first real-time communication service end transmitting the added video stream may provide an RTP stream group identifier to which the added video stream will be added to a second real-time service end receiving the video stream. The RTP stream group identifier may be transmitted as an item in an RTP extension header and / or SDES (Source Description) RTCP packet, and its value may be the associated ssrc-group-id attribute value when referencing an existing RTP stream group, and may include the SSRC value of the RTP stream and the RTP stream group identifier of the newly created RTP stream group when referencing an existing RTP stream with independent QoS requirements. A first real-time communication service end transmitting the added video stream and / or a second real-time communication service end that has obtained an RTP stream group identifier for the added RTP stream from the real-time communication service end can update a QoS request based thereon so that the SSRC value of the added RTP stream is included in the QoS flow mapping.

[0287] Although the above-described embodiments only describe cases where QoS information attributes (qos-info or qos-group-info) exist at the media description level, QoS information attributes may also be provided as session-level attributes. In this case, the identifiers representing the RTP stream of the QoS information attributes may further include information capable of identifying the media description to which the RTP stream belongs. For example, the information capable of identifying the media description may be the a=mid attribute value included in the media description.

[0288] It should be noted that the configuration diagrams, exemplary diagrams of control / data signal transmission and reception methods, and exemplary diagrams of operation procedures illustrated in FIGS. 1 through 11 are not intended to limit the scope of the embodiments of the present disclosure. That is, all components, entities, or steps of operation described in FIGS. 1 through 7 should not be interpreted as essential components for implementing the disclosure, and may be implemented to the extent that the essence of the disclosure is not compromised even if only some components are included.

[0289] FIG. 12 is a block diagram illustrating the structure of a user terminal according to one embodiment of the present disclosure.

[0290] Referring to FIG. 12, the user terminal may include a transceiver (1210), a control unit (1220), and a storage unit (1230). In the present invention, the control unit may be defined as a circuit or an application-specific integrated circuit or at least one processor.

[0291] The transmitting and receiving unit (1210) can transmit and receive signals with other network entities. The transmitting and receiving unit (510) can, for example, receive media data from a data network.

[0292] The control unit (1220) can control the overall operation of the user terminal according to the embodiment proposed in the present invention. For example, the control unit (1220) can control the establishment, control, etc. of a media transmission session to perform media transmission within the user terminal for a media client to perform media transmission.

[0293] The storage unit (1230) can store at least one of the information transmitted and received through the transmission and reception unit (1210) and the information generated through the control unit (1220). For example, the storage unit (1230) can store service connection information received from AF and media data received from AS.

[0294] FIG. 13 is a block diagram illustrating a network entity according to one embodiment of the present disclosure.

[0295] The network entity illustrated in FIG. 13 may be composed of one of the various types of network entities disclosed in the present invention, for example, UPF, AMF, SMF, PCF, UDM, NEF, AUSF, NRF, etc.

[0296] Referring to FIG. 13, a network entity may include a transceiver (1310), a control unit (1320), and a storage unit (1330). In the present invention, the control unit may be defined as a circuit or an application-specific integrated circuit or at least one processor.

[0297] The transmitting and receiving unit (1310) can transmit and receive signals with other network entities. The transmitting and receiving unit (1310) can receive, for example, request messages for various information from a user terminal, a base station, or other network entities.

[0298] The control unit (1320) can control the overall operation of a network entity according to an embodiment proposed in the present invention. For example, the control unit (1320) can control the network entity to provide a media transmission traffic processing policy to AF according to an embodiment disclosed in the present invention.

[0299] The storage unit (1330) can store at least one of the information transmitted and received through the transmission and reception unit (1310) and the information generated through the control unit (1320).

[0300] The operations of the embodiments described above can be realized by providing a memory device storing the corresponding program code in any component within the device. That is, the control unit within the device can execute the operations described above by reading the program code stored in the memory device by a processor or a CPU (Central Processing Unit) and executing it.

[0301] The entities or various components of terminal devices and modules described in this disclosure may be operated using hardware circuits, such as, for example, complementary metal oxide semiconductor-based logic circuits, firmware, software, and / or a combination of hardware and firmware and / or software embedded in a machine-readable medium. For example, various electrical structures and methods may be implemented using electrical circuits such as transistors, logic gates, and application-specific semiconductors.

[0302] Methods according to the claims or embodiments described in the specification of the present disclosure may be implemented in the form of hardware, software, or a combination of hardware and software.

[0303] When implemented in software, a computer-readable storage medium may be provided for storing one or more programs (software modules). One or more programs stored in the computer-readable storage medium are configured for execution by one or more processors within an electronic device. One or more programs include instructions that cause the electronic device to execute methods according to the claims or embodiments described in the specification of this disclosure.

[0304] These programs (software modules, software) may be stored in random access memory, non-volatile memory including flash memory, read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic disc storage device, compact disc-ROM (CD-ROM), digital versatile discs (DVDs), or other forms of optical storage devices, magnetic cassettes. Alternatively, they may be stored in a memory composed of some or all of these. Additionally, each constituent memory may include multiple units.

[0305] Additionally, the program may be stored on an attachable storage device that can be accessed via a communication network such as the Internet, Intranet, LAN (local area network), WAN (wide area network), or SAN (storage area network), or a combination thereof. Such a storage device may be connected to a device performing an embodiment of the present disclosure through an external port. Additionally, a separate storage device on a communication network may be connected to a device performing an embodiment of the present disclosure.

[0306] In the specific embodiments of the present disclosure described above, the components included in the present disclosure are expressed in a singular or plural form according to the specific embodiments presented. However, the singular or plural expression is selected to suit the situation presented for convenience of explanation, and the present disclosure is not limited to singular or plural components; even if a component is expressed in the plural, it may be composed of a singular form, and even if a component is expressed in the singular form, it may be composed of a plural form.

[0307] Meanwhile, although specific embodiments have been described in the detailed description of the present disclosure, it is understood that various modifications are possible within the scope of the present disclosure. Therefore, the scope of the present disclosure should not be limited to the described embodiments, but should be defined by the claims set forth below as well as equivalents thereof.

[0308] The electronic device for implementing, operating, and performing the various embodiments of the present disclosure may be of various forms. The electronic device may include, for example, a portable communication device (e.g., a smartphone), a computer device, a portable multimedia device, a portable medical device, a camera, a wearable device, or a consumer electronics device. The electronic device according to the embodiments of the present disclosure is not limited to the aforementioned devices.

[0309] The various embodiments of the present disclosure and the terms used therein are not intended to limit the technical features described in this document to specific embodiments, and should be understood to include various modifications, equivalents, or substitutions of such embodiments. In connection with the description of the drawings, similar reference numerals may be used for similar or related components. The singular form of a noun corresponding to an item may include one or more items unless the relevant context clearly indicates otherwise. In the present disclosure, each of the phrases such as “A or B”, “at least one of A and B”, “at least one of A or B”, “A, B or C”, “at least one of A, B and C”, and “at least one of A, B, or C” may include any one of the items listed together in the corresponding phrase, or all possible combinations thereof. Terms such as “first,” “second,” or “first” or “second” may be used simply to distinguish a component from another component and do not limit the components in any other aspect (e.g., importance or order). Where any (e.g., first) component is referred to as “coupled” or “connected” to another (e.g., second) component, with or without the terms “functionally” or “communicationly,” it means that the component may be connected to the other component directly (e.g., via a wire), wirelessly, or through a third component.

[0310] The term “module” as used in various embodiments of the present disclosure may include a unit implemented in hardware, software, or firmware, and may be used interchangeably with terms such as logic, logic block, component, or circuit, for example. A module may be a component formed integrally or a minimum unit of a component or part thereof that performs one or more functions. For example, according to one embodiment, a module may be implemented in the form of an application-specific integrated circuit (ASIC).

[0311] Various embodiments of the present disclosure may be implemented as software (e.g., a program) comprising one or more instructions stored in a storage medium (e.g., internal memory or external memory) readable by a machine (e.g., an electronic device). For example, a processor (e.g., a processor) of the machine (e.g., an electronic device) may call at least one of the one or more instructions stored from the storage medium and execute it. This enables the machine to operate to perform at least one function according to at least one called instruction. One or more instructions may include code generated by a compiler or code that can be executed by an interpreter. The storage medium readable by the machine may be provided in the form of a non-transitory storage medium. Here, "non-transitory" simply means that the storage medium is a tangible device and does not contain a signal (e.g., electromagnetic waves), and this term does not distinguish between cases where data is stored semi-permanently and cases where it is stored temporarily in the storage medium.

[0312] According to one embodiment, the method according to various embodiments of the present disclosure may be provided by being included in a computer program product. The computer program product may be traded between a seller and a buyer as a product. The computer program product may be distributed in the form of a device-readable storage medium (e.g., compact disc read-only memory (CD-ROM)), or distributed online (e.g., download or upload) through an application store (e.g., Play Store™) or directly between two user devices (e.g., smartphones). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily created in a device-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or a relay server.

[0313] According to various embodiments, each component (e.g., module or program) of the described components may include a singular or multiple entities, and some of the multiple entities may be separated and placed in other components. According to various embodiments, one or more of the aforementioned components or operations may be omitted, or one or more other components or operations may be added. Generally or additionally, multiple components (e.g., module or program) may be integrated into a single component. In this case, the integrated component may perform one or more functions of each of the multiple components in the same or similar manner as they were performed by the corresponding component among the multiple components prior to integration. According to various embodiments, operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically; one or more of the operations may be executed in a different order; may be omitted; or one or more other operations may be added. < / direction> < / direction>

Claims

1. A method performed by a terminal in a wireless communication system, A step of receiving service guidance information from an application provider - obtaining configuration information to request the setting of a dynamic policy to be applied to a media transmission session of a real-time media communication (RTC) service based on the service guidance information; A step of establishing a media transmission session including at least one media stream based on negotiation with an RTC endpoint participating in the real-time communication service; and The method includes the step of transmitting a request for the setting of the dynamic policy as an AF (application function); The above request includes identification information of the at least one media stream and quality of service (QoS) requirements for the at least one media stream, and A method of a terminal characterized in that the above identification information and the above QoS requirements are determined based on the above negotiation.

2. In Paragraph 1, The above negotiation with the above RTC terminator is, A step of transmitting a session description protocol (SDP) offer for at least one media stream to the above RTC termination; and The method includes the step of receiving an SDP answer for at least one media stream from the above RTC terminal, and The above SDP proposal and the above SDP response include parameters for the above QoS requirements, and A method of a terminal characterized in that the above parameters include at least one of a parameter for a desired bandwidth, a parameter for a supported bandwidth, a parameter for a required bandwidth, a parameter for a maximum packet loss rate, a parameter for a maximum packet error rate, or a parameter for a packet delay time.

3. In Paragraph 1, When a second media stream of the same type as a first media stream included in at least one media stream is added to the media transmission session, a step of verifying a second QoS requirement based on the first media stream and the second media stream - the media parameters of the second media stream correspond to the media parameters of the first media stream; If the second QoS requirement corresponds to the first QoS requirement of the first media stream, the step of transmitting the second media stream to the RTC termination without negotiation; and If the second QoS requirement does not correspond to the first QoS requirement, the method further includes the step of re-performing the negotiation and, based thereon, transmitting a QoS update request for the second QoS requirement to the AF. The above negotiation corresponds to the negotiation for the first media stream, and A method of a terminal characterized by updating the dynamic policy based on the above QoS update request.

4. In Paragraph 1, The identification information of at least one media stream includes identification information of each of the at least one media streams and identification information of a media stream group, and A method of a terminal characterized in that the media stream group comprises media streams having the same QoS requirements among at least one media stream.

5. In Paragraph 1, A step of receiving a response from the above AF including the setting result of the dynamic policy; and A method of a terminal further comprising the step of performing media stream transmission and reception with the RTC terminal based on the above setting result.

6. In a method performed by an application function (AF) in a wireless communication system, A step of establishing a provisioning session associated with a dynamic policy to be applied to a media transmission session of an application provider and a real-time media communication (RTC) service; A step of receiving a request for the setting of the dynamic policy from a terminal—the request includes identification information of at least one media stream included in the media transmission session and a quality of service (QoS) requirement for the at least one media stream, wherein the identification information and the QoS requirement are received based on negotiation between the terminal and the RTC endpoint; and The method includes the step of transmitting a QoS provision request related to the dynamic policy to a PCF (policy control function); A method of AF characterized in that the above QoS provision request includes the above identification information and the above QoS requirements.

7. In Paragraph 6, The above negotiation includes the transmission of a session description protocol (SDP) offer for at least one media stream to the RTC end of the terminal and the reception of an SDP answer from the RTC end. The above SDP proposal and the above SDP response include parameters for the above QoS requirements, and The above parameters include at least one of a parameter for desired bandwidth, a parameter for supported bandwidth, a parameter for required bandwidth, a parameter for maximum packet loss rate, a parameter for maximum packet error rate, or a parameter for packet delay time. In the above media transmission session, a second media stream of the same type as a first media stream included in at least one media stream is added, and if a second QoS requirement based on the first media stream and the second media stream corresponds to a first QoS requirement of the first media stream, the second media stream is transmitted from the terminal to the RTC termination without negotiation. The second media stream is added to the media transmission session, and if the second QoS requirement does not correspond to the first QoS requirement, a QoS update request for the second QoS requirement is received from the terminal based on the re-execution of the negotiation, and The above negotiation corresponds to the negotiation for the first media stream, and Based on the above QoS update request, the above dynamic policy is updated, and A method of AF characterized in that the media parameters of the second media stream correspond to the media parameters of the first media stream.

8. In Paragraph 6, A step of receiving a QoS provision response related to the setting result of the dynamic policy from the above PCF; and The method further includes the step of transmitting a response including the setting result of the dynamic policy to the terminal. Based on the above setting result, the transmission and reception of the at least one media stream between the terminal and the RTC end is performed, and The identification information of at least one media stream includes identification information of each of the at least one media streams and identification information of a media stream group, and A method of AF characterized in that the media stream group includes media streams having the same QoS requirements among the at least one media stream.

9. In a terminal in a wireless communication system, the terminal, Transmitter / receiver; At least one processor connected to the above-mentioned transmitting and receiving unit to enable communication; and The terminal is connected to communicate with the at least one processor and is executable by the at least one processor, so that the terminal, Receive service guidance information from an application provider - and obtain configuration information to request the setting of a dynamic policy to be applied to a media transmission session of a real-time media communication (RTC) service based on the said service guidance information, Based on negotiation with an RTC endpoint participating in the above real-time communication service, the media transmission session including at least one media stream is established, and It includes a memory that stores an application function AF that causes a request for setting the dynamic policy to be transmitted, and The above request includes identification information of the at least one media stream and quality of service (QoS) requirements for the at least one media stream, and A terminal characterized in that the above identification information and the above QoS requirements are determined based on the above negotiation.

10. In Paragraph 9, The above command is, in the above negotiation between the terminal and the RTC terminal To the above RTC termination, transmit a session description protocol (SDP) offer for the at least one media stream, and Further causing to receive an SDP answer for at least one media stream from the above RTC termination, and The above SDP proposal and the above SDP response include parameters for the above QoS requirements, and A terminal characterized by including at least one of the above parameters, a parameter for a desired bandwidth, a parameter for a supported bandwidth, a parameter for a required bandwidth, a parameter for a maximum packet loss rate, a parameter for a maximum packet error rate, or a parameter for a packet delay time.

11. In Paragraph 9, The above command, the terminal, In the above media transmission session, if a second media stream of the same type as a first media stream included in at least one media stream is added, a second QoS requirement based on the first media stream and the second media stream is determined, and - the media parameters of the second media stream correspond to the media parameters of the first media stream. If the above second QoS requirement corresponds to the first QoS requirement of the first media stream, the second media stream is transmitted to the RTC termination without the above negotiation, and If the above second QoS requirement does not correspond to the above first QoS requirement, the above negotiation is re-executed and, based thereon, further causes the AF to send a QoS update request for the above second media stream, and The above negotiation corresponds to the negotiation for the first media stream, and A terminal characterized by the dynamic policy being updated based on the above QoS update request.

12. In Paragraph 9, The above command is, the terminal From the above AF, receive a response including the setting result of the dynamic policy, and Based on the above setting result, it further causes the transmission and reception of media streams with the RTC end to be performed, and The identification information of at least one media stream includes identification information of each of the at least one media streams and identification information of a media stream group, and A terminal characterized in that the media stream group above includes media streams having the same QoS requirements among at least one media stream.

13. In an application function (AF) in a wireless communication system, the AF is, Transmitter / receiver; At least one processor connected to the above-mentioned transmitting and receiving unit to enable communication; and Connected to communicate with at least one processor and executable by at least one processor, the AF, Establish a provisioning session associated with a dynamic policy to be applied to the media transmission session of the application provider and the real-time media communication (RTC) service, and A request for the setting of the dynamic policy is received from a terminal—the request includes identification information of at least one media stream included in the media transmission session and a quality of service (QoS) requirement for the at least one media stream, wherein the identification information and the QoS requirement are received based on negotiation between the terminal and the RTC endpoint, and It includes a memory that stores a command that causes a QoS provision request related to the dynamic policy to be transmitted as a PCF (policy control function); AF, characterized in that the above QoS provision request includes the above identification information and the above QoS requirements.

14. In Paragraph 13, The above negotiation includes the transmission of a session description protocol (SDP) offer for at least one media stream to the RTC end of the terminal and the reception of an SDP answer from the RTC end. The above SDP proposal and the above SDP response include parameters for the above QoS requirements, and The above parameters include at least one of a parameter for desired bandwidth, a parameter for supported bandwidth, a parameter for required bandwidth, a parameter for maximum packet loss rate, a parameter for maximum packet error rate, or a parameter for packet delay time. In the above media transmission session, a second media stream of the same type as a first media stream included in at least one media stream is added, and if a second QoS requirement based on the first media and the second media stream corresponds to a first QoS requirement of the first media stream, the second media stream is transmitted from the terminal to the RTC termination without negotiation. The second media stream is added to the media transmission session, and if the second QoS requirement does not correspond to the first QoS requirement, a QoS update request for the second QoS requirement is received from the terminal based on the re-execution of the negotiation, and The above negotiation corresponds to the negotiation for the first media stream, and Based on the above QoS update request, the above dynamic policy is updated, and AF, characterized in that the media parameters of the second media stream correspond to the media parameters of the first media stream.

15. In Paragraph 13, The above command, the above AF, From the above PCF, receive a QoS provision response related to the setting result of the above dynamic policy, and Further causing the above terminal to transmit a response including the setting result of the dynamic policy, and Based on the above setting result, the transmission and reception of the at least one media stream between the terminal and the RTC end is performed, and The identification information of at least one media stream includes identification information of each of the at least one media streams and identification information of a media stream group, and AF, wherein the media stream group comprises media streams having the same QoS requirements among at least one media stream.

Images