Method and apparatus for rtcp packet filtering in wireless communication system

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting higher data transmission rates. A method performed by a first node in a wireless communication system, according to one embodiment of the present disclosure, comprises the steps of: transmitting, to a second node, a session description protocol (SDP) proposal message including proposal information about at least one media transmission sub-session; and receiving, from the second node, an SDP response message including information indicating whether the proposal information has been accepted, wherein a media transmission session between the first node and the second node can be established on the basis of the information indicating whether the proposal information has been accepted.

Description

Method and device for RTCP packet filtering in a wireless communication system

[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 the characteristics of the RTCP protocol.

[0002] 5G mobile communication technology defines a wide frequency band to enable fast transmission speeds and new services, and can be implemented not only in frequency bands below 6 GHz ('Sub 6 GHz'), such as 3.5 gigahertz (3.5 GHz), but also in ultra-high frequency bands called millimeter waves (mmWave), such as 28 GHz and 39 GHz ('Above 6 GHz'). In addition, for 6G mobile communication technology, which is referred to as a system beyond 5G, implementation in the terahertz band (e.g., the 3 terahertz (3 THz) band at 95 GHz) is being considered to achieve transmission speeds 50 times faster and ultra-low latency reduced to one-tenth compared to 5G mobile communication technology.

[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 such as beamforming and Massive MIMO to mitigate path loss and increase transmission distance in ultra-high frequency bands, support for various numerologies (such as the operation of multiple subcarrier spacing) and dynamic operation of slot formats for the efficient utilization of ultra-high frequency resources, initial access techniques to support multi-beam transmission and broadband, definition and operation of Band-Width Parts (BWP), Low Density Parity Check (LDPC) codes for high-volume data transmission, new channel coding methods such as Polar Codes for the reliable transmission of control information, and L2 pre-processing (L2 Standardization has been carried out for pre-processing, network slicing which provides a dedicated network specialized for specific services, and other methods.

[0004] Currently, discussions are underway to improve and enhance the performance of the initial 5G mobile communication technology, taking into account the services that the 5G mobile communication technology was intended to support. Additionally, standardization of the physical layer is in progress for technologies such as V2X (Vehicle-to-Everything), which helps autonomous vehicles make driving decisions and enhance user convenience based on their own location and status information transmitted by the vehicle; NR-U (New Radio Unlicensed), which aims for system operation in unlicensed bands to comply with various regulatory requirements; NR terminal low power consumption technology (UE Power Saving); Non-Terrestrial Network (NTN), which is direct terminal-satellite communication for securing coverage in areas where communication with the terrestrial network is impossible; and positioning.

[0005] In addition, standardization is underway in the field of wireless interface architecture / protocols for technologies such as the 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 links and access links, Mobility Enhancement including Conditional Handover and Dual Active Protocol Stack (DAPS) Handover, and 2-step Random Access for NR which simplifies random access procedures. Standardization is also underway in the field of system architecture / services for 5G baseline architectures (e.g., Service based Architecture, Service based Interface) to incorporate Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC), which provides services based on the location of the terminal.

[0006] When 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 functionality and performance of 5G mobile communication systems and to integrate the operation of connected devices. To this end, new research is planned to be conducted on 5G performance improvement and complexity reduction, support for AI services, support for metaverse services, and drone communication using eXtended Reality (XR), Artificial Intelligence (AI), and Machine Learning (ML) to efficiently support Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR).

[0007] Furthermore, the advancement of these 5G mobile communication systems encompasses multi-antenna transmission technologies such as new waveforms to guarantee coverage in the terahertz band of 6G mobile communication technology, Full Dimensional MIMO (FD-MIMO), array antennas, and large-scale antennas; metamaterial-based lenses and antennas to improve terahertz band signal coverage; high-dimensional spatial multiplexing technology using OAM (Orbital Angular Momentum); and Reconfigurable Intelligent Surface (RIS) technology; as well as Full Duplex technology for enhancing frequency efficiency and system networks in 6G mobile communication technology; AI-based communication technologies that realize system optimization by utilizing satellites and AI from the design stage and internalizing end-to-end AI support functions; and the realization of services of complexity exceeding the limits of terminal computing capabilities by utilizing ultra-high-performance communication and computing resources. It could serve as a foundation for the development of next-generation distributed computing technologies.

[0008] 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 a prerequisite. While the aforementioned various media data formats may each possess diverse transmission characteristics, they are frequently transmitted as multiplexed single IP packet flows for the convenience of service operation. Reflecting this, discussions are ongoing regarding the effective classification and processing of media data with diverse transmission characteristics contained within a single IP packet flow, as well as the allocation of network resources.

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

[0010] In addition, one objective of the present disclosure is to provide a method and apparatus for configuring a media transmission subsession including media streams having the same transmission characteristics, taking into account the transmission characteristics of each media stream, and requesting a QoS flow optimized for each media transmission subsession.

[0011] Additionally, one object of the present disclosure is to provide a method and apparatus for allocating network resources using a QoS flow comprising one or more media transmission subsessions, and allocating a control channel shared by media streams to a media transmission subsession to which an associated media stream belongs.

[0012] 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.

[0013] In one embodiment of the present disclosure, a method performed by a first node in a wireless communication system includes the steps of transmitting a Session Description Protocol (SDP) proposal message containing proposal information for at least one media transmission subsession to a second node, and receiving an SDP response message from the second node containing information indicating whether to accept the proposal information, and a media transmission session between the first node and the second node may be established based on the information indicating whether to accept the proposal information.

[0014] In one embodiment of the present disclosure, a method performed by a second node in a wireless communication system comprises receiving a Session Description Protocol (SDP) offer message containing offer information for at least one media transmission subsession from a first node, and transmitting an SDP answer message containing information indicating whether to accept the offer information to the first node, and a media transmission session between the first node and the second node may be established based on the information indicating whether to accept the offer information.

[0015] In one embodiment of the present disclosure, a first node in a wireless communication system comprises at least one transceiver, at least one processor connected to at least one transceiver; and at least one memory connected to at least one processor, wherein the at least one memory stores instructions executable by at least one processor, such that the first node transmits a Session Description Protocol (SDP) offer message containing offer information for at least one media transmission subsession to a second node, and receives an SDP answer message from the second node containing information indicating whether to accept the offer information, and a media transmission session between the first node and the second node can be established based on the information indicating whether to accept the offer information.

[0016] In one embodiment of the present disclosure, a second node in a wireless communication system comprises at least one transceiver, at least one processor connected to at least one transceiver, and at least one memory connected to at least one processor, wherein the at least one memory stores an instruction executable by at least one processor that causes the second node to receive a Session Description Protocol (SDP) offer message containing offer information for at least one media transmission subsession from a first node and to transmit an SDP answer message containing information indicating whether to accept the offer information to the first node, and a media transmission session between the first node and the second node can be established based on the information indicating whether to accept the offer information.

[0017] The various embodiments 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 embodiments of the present disclosure can be derived and understood by those skilled in the art based on the detailed description to be described below.

[0018] The existing QoS request method based on 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.

[0019] However, according to one example of the present disclosure, an AF (e.g., media AF or P-CSCF) may transmit information regarding QoS requirements to a network for each media transmission subsession, and the network may configure a QoS flow optimized for the stream transmission characteristics included in each media transmission subsession, thereby enabling the network to communicate while reflecting the requirements of each media stream. Additionally, when media streams share a single control channel, the control channel may be assigned to media transmission subsessions according to the associated media streams, and a QoS flow including one or more media transmission subsessions may be configured.

[0020] 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.

[0021] 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).

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

[0023] 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.

[0024] 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.

[0025] 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.

[0026] 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.

[0027] 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.

[0028] 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.

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

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

[0031] FIG. 11 is a drawing illustrating the configuration of a terminal according to one embodiment of the present disclosure.

[0032] FIG. 12 is a diagram illustrating the configuration of a base station or network entity according to one embodiment of the present disclosure.

[0033] FIG. 13 is a block diagram of a network entity (1300) that performs network functions according to one embodiment of the present disclosure.

[0034] FIG. 14 is a flowchart illustrating an example of a method performed by a first node in one embodiment of the present disclosure.

[0035] FIG. 15 is a flowchart illustrating an example of a method performed by a second node in one embodiment of the present disclosure.

[0036] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the attached drawings.

[0037] In describing the embodiments, technical details that are well known in the art to which this disclosure belongs and are not directly related to this disclosure are omitted. This is intended to convey the essence of this disclosure more clearly without obscuring it by omitting unnecessary explanations.

[0038] 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 or different reference numbers.

[0039] 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. However, the present disclosure is not limited to the embodiments disclosed below but may be implemented in various different forms. These embodiments are provided merely to ensure that the disclosure is complete and to fully inform those skilled in the art of the scope of the disclosure, 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. Furthermore, in describing the present disclosure, if it is determined that a detailed description of a related function or configuration might unnecessarily obscure the essence of the present disclosure, such detailed description is omitted. Additionally, the terms described below are defined considering their functions in the present disclosure, and these may vary depending on the intentions or conventions of the user or operator. Therefore, their definitions should be based on the content throughout the specification.

[0040] In the present disclosure, it will be understood that each block of the process flow diagrams and combinations of the flow diagrams may be performed based on computer program instructions. Since these computer program instructions may be optionally loaded into at least one processor of a general-purpose computer, a computer for special purposes, or other programmable data processing equipment, the instructions performed through any one or any combination of at least one processor of the computer or other programmable data processing equipment create means for performing the functions described in the flow diagram block(s). Since these computer program instructions may 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 functions in a specific manner, the instructions stored in computer-available or computer-readable memory may also produce a manufactured item containing means of instruction for performing the functions 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 operation steps on the computer or other programmable data processing equipment to create a process executed by the computer can also provide steps for executing the functions described in the flowchart block(s).

[0041] 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 example, two blocks (or functions) described in succession may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order according to the corresponding function.

[0042] As used in the embodiments of the present disclosure, the term “part” refers to a software or hardware component, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC), and the “part” performs certain roles. However, the term including “part” is not limited to software or hardware. The “part” may be configured to reside in an addressable storage medium or may be configured to run on one or more processors. Thus, by 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 utilize one or more CPUs (central processing units) within the device or secure multimedia card. Also, in the embodiments, 'parts' may include one or more processors.

[0043] As stated above, it should be noted that the blocks of each flowchart and combinations of flowcharts described in this disclosure may be executed by one or more computer programs including instructions. The entirety of one or more computer programs may be stored in a single memory device, or one or more computer programs may be divided into different parts and stored across multiple memory devices.

[0044] Additionally, any / any function or operation described in this disclosure may be processed by a single processor or a combination of processors. The single processor or combination of processors is a circuitry that performs processing and may include an application processor (AP, e.g., a central processing unit (CPU)), a communication processor (CP, e.g., a modem), a graphics processing unit (GPU), a neural network processing unit (NPU) (e.g., an artificial intelligence (AI) chip), a Wi-Fi chip, a Bluetooth® chip, a global positioning system (GPS) chip, a near-field communication (NFC) chip, a connectivity chip, a sensor controller, a touch controller, a fingerprint sensor controller, a display driver integrated circuit (IC), an audio codec (CODEC) chip, a universal serial bus (USB) controller, a camera controller, an image processing IC, a microprocessor unit (MPU), a system-on-chip (SoC), an IC, or similar circuitry.

[0045] Additionally, it should be noted that various embodiments in the claims and description of the present disclosure may be implemented in the form of hardware, software, or a combination of hardware and software.

[0046] Such software may be stored on a non-transitory computer-readable storage medium. A non-transitory computer-readable storage medium stores one or more computer programs (software modules), and said one or more computer programs include computer-executable instructions that operate an electronic device to perform a method according to the present disclosure when executed alone or collectively by one or more processors of an electronic device.

[0047] The software may be stored in a transient or non-transient storage device, for example, in the form of read-only memory (ROM) (whether or not it is erasable or rewritable), or random access memory (RAM), memory chips, devices, or integrated circuits (ICs). Additionally, the software may be stored in the form of an optically or magnetically readable medium, for example, a compact disc (CD), a digital multifunction disc (DVD), a magnetic disc, or a magnetic tape. It should be understood that the storage device and the storage medium are examples of non-transient machine-readable storage media suitable for storing programs for implementing various embodiments of the present disclosure. Accordingly, various embodiments of the present disclosure may provide a program containing code for implementing a device or method according to any one of the claims of this specification, and a non-transient machine-readable storage medium storing such program.

[0048] In the following disclosure, determining the priority between A and B may be referred to in various ways, such as selecting the one with the higher priority according to a predetermined priority rule and performing the corresponding action, or omitting or dropping the action for the one with the lower priority.

[0049] Hereinafter, 'A or B' as described in the present disclosure may be understood as 'A and / or B', which may be understood as including 'A', or 'B', or 'A and B'.

[0050] Additionally, 'at least one of A, B, and C' described in the present disclosure may be understood to include 'A', or 'B', or 'C', or 'any combination of A, B, and C'.

[0051] Additionally, 'at least one of A, B, or C' described in the present disclosure may be understood to include 'A', or 'B', or 'C', or 'any combination of A, B, and C'.

[0052] Additionally, 'A / B' as described in the present disclosure may be understood as 'A and / or B', which may be understood as including 'A', or 'B', or 'A and B'.

[0053] Additionally, 'A, B' described in the present disclosure may be understood as 'A and / or B', which may be understood as including 'A', or 'B', or 'A and B'.

[0054] Additionally, 'A and B' described in the present disclosure may be understood as 'A and / or B', which may be understood as including 'A', or 'B', or 'A and B'.

[0055] Furthermore, the phrase "when conditions A and B are satisfied" as described in the present disclosure is not necessarily limited to cases where both conditions A and B are satisfied, but may be understood to include cases where either condition A or condition B is satisfied individually, cases where both conditions A and B are satisfied, or cases where one or more additional conditions are satisfied together.

[0056] Furthermore, throughout this specification, ordinal terms (and similar modifiers) such as 'first', 'second', 'third', etc. are used solely for the purpose of distinguishing various instances, occurrences, configurations, messages, stages, or aspects of elements, operations, or information, as described below. Unless clearly required otherwise by the context, the use of such ordinal terms does not require that the elements, operations, or information distinguished by such terms be structurally different, numerically distinct, or essentially different. For example, 'first signal' and 'second signal' may represent instances of the same signal transmitted at different times, signals containing the same core information even with some variations, or signals having different content or characteristics depending on the specific context. Similarly, 'first value' and 'second value' may represent the same magnitude measured or applied in different situations, or may represent different magnitudes. Such interpretation must be determined based on the specific technical context, function, and relationship described in the relevant parts of the specification and claims.

[0057] Furthermore, although terms such as "first," "second," etc., as used in this disclosure are used for various elements such as information, objects, actions, and sequences, they are not intended to limit such elements to a specific order. These terms may be understood merely as distinguishing one element from another. For example, a first element may be referred to as a second element, and likewise, a second element may be referred to as a first element.

[0058] Additionally, the terms 'first' and 'second' described in this disclosure may be understood to refer to identical or different elements. For example, if an element is information, the first information and the second information may both be information, and depending on the case, they may be the same information or different information.

[0059] Furthermore, the expressions 'if' and 'in case that' described in this disclosure or claims may be interpreted, depending on the context, as meaning 'when or upon,' 'in response to,' 'based on,' or 'according to,' and these expressions may be used interchangeably. In addition, other expressions having substantially the same meaning may be used as substitutes, provided that they do not impair the technical features of this disclosure.

[0060] Additionally, the term "not perform" as used in this disclosure or claims may be understood, depending on the context, to mean to omit or skip the corresponding step. Such a term may be replaced with other terms having the same or substantially similar meaning.

[0061] Additionally, the phrase "transmitting a message containing A and B" as described in this specification may be interpreted to include not only (i) cases where A and B are transmitted as a single message, but also (ii) cases where A and B are transmitted individually through multiple messages (e.g., transmitting a first message containing A and a second message containing B). This interpretation may also apply to cases where messages containing two or more items, such as A, B, and C, are transmitted together or individually.

[0062] In addition, 'transmitting a message containing A and transmitting a message containing B' can also be interpreted as transmitting a single message containing A and B.

[0063] In the specific embodiments of the present disclosure described below, terms or components included in the disclosure will be expressed in the singular or plural form according to the specific embodiments presented. However, the singular or plural expression is selected to suit the circumstances 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 form, it may be composed in the singular form, and even if a component is expressed in the singular form, it may be composed in the plural form.

[0064] The drawings or flowcharts described below illustrate exemplary methods that may be implemented in accordance with the principles of the present disclosure, and various modifications may be made to the methods illustrated in the flowcharts of the present disclosure. For example, although illustrated as a series of steps, the various steps of each drawing or flowchart may overlap, occur in parallel, occur in a different order, or occur multiple times. In other examples, any step may be omitted or replaced with another step.

[0065] The methods and devices proposed in the embodiments of the present disclosure below are not limited to each embodiment and may be utilized as a combination of all or part of the embodiments proposed in the disclosure. Accordingly, the embodiments of the present disclosure may be applied with some modifications within the scope that does not deviate significantly from the scope of the present disclosure, at the judgment of a person skilled in the art.

[0066] In this case, any wording mentioned in different embodiments may be used interchangeably, combined, or substituted if the concepts correspond. For example, regarding the same or corresponding concepts, even if the expression 'A' is used in one embodiment and the expression 'B' is used in another embodiment, they may be understood by interchangeably, substituted, or combined.

[0067] Terms used in the following description to identify connection nodes, terms referring to network entities, terms referring to messages, terms referring to interfaces between network entities, terms referring to various identification information, etc., are examples provided for the convenience of explanation. Accordingly, the present disclosure is not limited to the terms described below, and other terms referring to objects having equivalent technical meanings may be used. Furthermore, where appropriate, such terms may be replaced with terms defined in the 3GPP (3rd generation partnership project) Technical Specifications (TS).

[0068] Hereinafter, the base station, as the entity performing resource allocation for terminals, may be at least one of gNode B, eNode B, Node B, BS (base station), wireless access unit, base station controller, or a node on a network. Additionally, the base station of the present disclosure may include a structure split into a central unit (CU) and a distributed unit (DU). In such a structure, the CU is responsible for the upper layer of the control and user plane, and the DU is responsible for wireless resource processing of the lower layer. The embodiments of the present disclosure can be equally applied to a 5G base station structure in which functions are separated into the CU and DU as described above.

[0069] The terminal may include a UE (user equipment), MS (mobile station), cellular phone, smartphone, computer, or a multimedia system capable of performing communication functions.

[0070] In the present disclosure, a downlink (DL) refers to a wireless transmission path of a signal transmitted by a base station to a terminal, and an uplink (UL) refers to a wireless transmission path of a signal transmitted by a terminal to a base station.

[0071] In addition, while a 5th generation mobile communication system (5G, new radio, NR) and a 6th generation mobile communication system (6G) may be described below as examples, embodiments of the present disclosure may also be applied to other communication systems having similar technical backgrounds or channel types. For example, new advanced mobile communication systems developed after 5G and 6G may be included therein. Furthermore, the present disclosure may be applied to other communication systems (e.g., Wi-Fi systems) with some modifications made in the judgment of a person with skilled technical knowledge, without significantly departing from the scope of the present disclosure.

[0072] In the following description, the terms "physical channel" and "signal" may be used interchangeably with "data" or "control signal." For example, PDSCH (physical downlink shared channel) is a term referring to a physical channel through which data is transmitted, but PDSCH may also be used to refer to data. That is, in this disclosure, the expression "transmits a physical channel" may be interpreted as equivalent to the expression "transmits data or a signal through a physical channel."

[0073] In describing the present disclosure below, the term "upper layer signaling" may be a signaling corresponding to at least one or a combination of at least one of MIB (master information block), SIB (system information block), SIB M (M=1, 2, …), RRC (radio resource control), MAC (medium access control), CE (control element), NAS (non-access stratum) signaling, or application layer messages. The RRC signaling may also be referred to as L3 signaling (layer 3 signaling).

[0074] Additionally, L1 signaling may be a signaling method corresponding to at least one or a combination of at least one of the following: a physical layer channel or signaling of a PDCCH (physical downlink control channel), a DCI (downlink control information), a UE-specific DCI, a group common DCI, a common DCI, a scheduling DCI (e.g., a DCI used for the purpose of scheduling downlink or uplink data), a non-scheduling DCI (e.g., a DCI not used for the purpose of scheduling downlink or uplink data), a PUCCH (physical uplink control channel), or an UCI (uplink control information). The above L1 signaling may also be referred to as physical layer signaling.

[0075] Hereinafter, the expression in the present disclosure or claims that information can be configured from a base station may mean that, depending on the context, a terminal receives said information from a base station through physical layer signaling or upper layer signaling, and such expression may be replaced with other terms having the same or substantially similar meaning.

[0076] The operating principle of the present disclosure will be explained in detail below with reference to the attached drawings.

[0077] 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.

[0078] 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.

[0079] 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.

[0080] 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.

[0081] 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.

[0082] 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.

[0083] 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."

[0084] 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.

[0085] 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.

[0086] 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.

[0087] 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.

[0088] 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.

[0089] 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).

[0090] 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.

[0091] The present disclosure relates to a method and apparatus for applying network resource allocation and packet processing policies by media in a wireless communication system. For example, the present disclosure relates to a method and apparatus for supporting media services including Real-Time Communication Service and Media Streaming Service.

[0092] 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 / or control channels and may be defined, for example, using a 5-tuple (source IP address, destination IP address, source port number, destination port number, protocol). The above control channel may be, for example, a channel through which RTCP (Real-Time Transport Control Protocol) packets are transmitted, and the RTCP packets may include a transmission report, a reception report, user identification information per RTP stream, a codec control message, etc., for media data transmitted via RTP.

[0093] 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.

[0094] 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.

[0095] 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.

[0096] The above media streams 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 having 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 is required to identify each media stream within the service data flow. Furthermore, if two or more media streams share a control channel, information is also required to identify the control channel packets associated with each media stream. In this case, the information for identifying the media streams and / or control channel packets per media stream, and their traffic characteristics, may be determined by negotiation between the media transmission device and the media reception device at the time of service initiation. Therefore, a procedure is required to provide the network with media stream and / or control channel packet identification information and transmission characteristics per media stream based on the above negotiation results.

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

[0098] 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.

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

[0100] 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 Next Generation Radio Access Network (NG-RAN) and a 5G Core Network (5GC). 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 Public Data Network (PDN) and can provide users with various forms of data services, including voice. The control plane components of the 5GC may be considered as Virtualized Network Functions (VNFs), and communication between VNFs may be considered as RESTful-based API exchanges in which one VNF provides services to other VNFs. An API-based communication interface between VNFs is called a Service Based Interface (SBI).

[0101] Referring to FIG. 1, the 5GS may include user equipment (UE) (101), NG-RAN (102) including a base station, a User Plane Function (UPF) device (103), an Access and Mobility Management Function (AMF) device (111), a Session Management Function (SMF) device (112), a Policy Control Function (PCF) device (113), a Network Exposure Function (NEF) device (114), an NF repository function (NRF) device (115), an authentication server function (AUSF) device (116), a Unified Data Management (UDM) device (117), an Application Function (AF) device (121), and an 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, Network Function, or Network Function Apparatus.

[0102] 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.

[0103] 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.

[0104] 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.

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

[0106] A wireless communication system according to the present disclosure may configure a QoS flow using a media transmission subsession as the minimum unit. The media transmission subsession may include one or more media streams having the same transmission characteristics and a control packet stream associated with the media stream, and the QoS flow may refer to a logical minimum unit to which the same packet processing policy is applied in a network.

[0107] 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). At this time, the first service data flow (210) may include a first media stream (211) belonging to a first media transmission subsession and a second media stream (212) belonging to a second media transmission subsession, and may further include a control channel (213) for controlling the first media stream (211) and the second media stream (212).

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

[0109] For example, it can be assumed that the first media stream (211) contains voice data and the second media stream (212) contains video data. In this case, the network may configure a first QoS flow (241) with a first media transmission subsession consisting of a first media stream (211) containing voice data and a control packet related to the first media stream (211) of the control channel (213), and may configure a second QoS flow (242) with a second media transmission subsession consisting of a second media stream (212) containing video data and a control packet related to the second media stream (212) of the control channel (213). In this case, a new header may be added to the packet input to the packet filter (230) for packet transmission between devices constituting the network.

[0110] 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, an RTP / RTCP packet header, an SDES item of an RTCP packet, and / or an RTP extension header).

[0111] 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).

[0112] 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).

[0113] 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.

[0114] 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.

[0115] Referring to FIG. 3, media data may be encapsulated into an RTP payload (311), and an RTP / UDP / IP packet (310) transmitting a media stream may include an RTP payload (311) containing media data and an RTP header (312), a UDP header (313), and an IP header (314) for processing the same in a network and media transmission / reception device. The RTP header (312) may include an RTP header extension. Referring to FIG. 3, control data may be encapsulated into an RTCP packet (321), and an RTCP / UDP / IP packet (320) transmitted to a control channel may include one or more RTCP packets (321) containing control data and a UDP header (322) and an IP header (323) for processing the same in a network and media transmission / reception device.

[0116] Referring to FIG. 3, the first 12 octets or 12 bytes of the RTP header (312) 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 (312) has the following meaning.

[0117] - 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.

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

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

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

[0121] - 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.

[0122] - 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).

[0123] - 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.

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

[0125] - SSRC: A 32-bit field representing the identifier of the synchronization source. It can be used to identify an RTP stream.

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

[0127] Referring to FIG. 3, the first 4 octets or 4 bytes of the RTCP packet (321) are included in all RTCP packets, and the structure of the subsequent information may vary depending on the RTCP packet format. Each field of the RTCP packet (321) has the following meaning.

[0128] - 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.

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

[0130] - Format-specific(FS): A 5-bit field that has different meanings depending on the RTCP packet format. For example, in the case of an RTCP sender report (PT=200), it can indicate the number of receive reports included in the corresponding RTCP packet.

[0131] - payload type (PT): An 8-bit field representing the RTCP packet type. The PT field values ​​for each RTCP packet type may follow a database (repository) managed by IANA (Internet Assigned Numbers Authority).

[0132] - Format-Specific Information: Fields that have different structures depending on the RTCP packet format. For example, it may include the identifier (SSRC) of the RTP stream transmitting the RTCP packet.

[0133] A media service according to an 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 (e.g., source IP address, destination IP address, source port number, destination port number, transport protocol). Accordingly, among the RTP / UDP / IP packets (310) and / or RTCP / UDP / IP packets (320) disclosed in FIG. 3, packets in which the source / destination IP address values ​​of the IP header (314, 323) and the source / destination port number values ​​of the UDP header (313, 322) are identical may be considered as packets belonging to a single media transport session. A media transport session according to the present disclosure may have a companion media transport session representing a packet flow in the opposite direction to the media transport session. For example, the above companion media transmission session can be identified as a 5-tuple, and its source IP address and source port number are the same as the destination IP address and destination port number of the associated media transmission session, and its destination IP address and destination port number may be the same as the source IP address and source port number of the associated media transmission session.

[0134] Referring to FIG. 3, the second octet of the RTP header (312) consists of a 1-bit M field and a 7-bit PT field (0–127), and the second octet of the RTCP packet (321) consists of an 8-bit PT field (0–255). When a single media transmission session contains both an RTP / UDP / IP packet (310) and an RTCP / UDP / IP packet (320), an RTP packet receiving device and / or a network packet filter may use the fields to distinguish between the RTP packet and the RTCP packet when the following conditions are satisfied:

[0135] - The PT field value (PT) that can be used in the RTP header (312) and the PT field value that can be used in the RTCP packet (320) must be different.

[0136] - For each PT field value (PT) that can be used in the RTP header (312), PT+128 must not be included in the PT field value that can be used in the RTCP packet (320).

[0137] For example, if the PT field value is equal to or greater than 192 and equal to or less than 255, the packet can be considered as an RTCP packet (320).

[0138] The above-mentioned media transmission session may include one or more synchronization sources, and the synchronization sources may transmit RTP streams and / or RTCP streams. Here, an RTP stream refers collectively to RTP packets transmitted by a specific synchronization source within a media transmission session, each packet having an SSRC field value assigned to the synchronization source and may contain 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. An RTCP stream may be defined as a set of RTCP packets in which the SSRC field value of the first RTCP packet among the RTCP / UDP / IP packets transmitted to the associated media transmission session is identical. A synchronization source transmitting an RTP stream may transmit an RTCP stream using the same SSRC value.

[0139] In a wireless communication system according to an embodiment of the present disclosure, a media transmission session may be divided into media transmission subsessions. For example, the media transmission subsessions may include all RTP streams and / or RTCP streams transmitted by one or more synchronization sources. In this case, the media transmission subsessions may be defined by a list of synchronization sources and the protocol of the packets transmitted by the synchronization sources included in the list, and the protocol may include at least one of RTP / UDP / IP and RTCP / UDP / IP. In a wireless communication system according to an embodiment of the present disclosure, the RTP streams included in the media transmission subsessions may have the same QoS requirements. An RTP packet according to the present disclosure may include an extension header containing an identifier of the associated media transmission subsession. A Source Description (SDES) RTCP packet (PT=202) according to the present disclosure may include a media transmission subsession SDES item indicating the identifier of the associated media transmission subsession.

[0140] In a wireless communication system according to an embodiment of the present disclosure, the AF (121) may provide the network with information for identifying packets belonging to a media transmission subsession and QoS requirements for the identified packets. A media transmission subsession according to an embodiment of the present disclosure may include, for example, an RTP stream and / or an RTCP stream. In this case, the information for identifying the RTP stream may include at least one of information for identifying the media transmission session to which the RTP stream belongs, an SSRC field value for identifying the RTP stream, and information for identifying the 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, a grouped RTP stream identifier, and an SSRC field value(s) for identifying individual RTP streams belonging to the grouped RTP stream. 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. The information for identifying an RTCP packet stream according to an embodiment of the present disclosure may include at least one of information for identifying a media transmission session to which the RTCP packet stream belongs, an SSRC field value for identifying the RTCP packet stream, and a grouped RTP stream identifier associated with the RTCP packet.

[0141] In a wireless communication system according to an embodiment of the present disclosure, the network may, taking into account the QoS requirements for a media transmission subsession provided by AF (121), 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 transmission subsessions. The media transmission subsession may, for example, include one or more RTP streams and / or RTCP streams. In this case, the filtering condition may include information for identifying the RTP streams and / or RTCP streams. The information for identifying the RTP streams according to the present disclosure may, for example, include at least one of information for identifying the media transmission session to which the RTP stream belongs, an SSRC field value for identifying the RTP stream, and information for identifying grouped RTP streams. The information for identifying the media transmission session may include a sending / receiving IP address and a UDP port number. 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, a grouped RTP stream identifier, and SSRC value(s) for identifying individual RTP streams belonging to the grouped RTP stream. The grouped RTP stream identifier may, for example, be included in an RTP extension header, 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.Information for identifying an RTCP stream according to the present disclosure may include, for example, at least one of information for identifying a media transmission session to which the RTCP stream belongs, an SSRC field value for identifying an RTP stream associated with an RTCP packet, and a grouped RTP stream identifier associated with an RTCP packet.

[0142] 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.

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

[0144] - Media AF (121): Application Function (AF) for providing media services

[0145] - Media AS (122): Application Server (AS) for media transmission

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

[0147] ■ Media Session Handler (411): An internal function of the UE (101) that communicates with the Media AF (121) to establish and control media transmission sessions.

[0148] ■ 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.

[0149] 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.

[0150] - 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.

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

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

[0153] - 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).

[0154] - 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.

[0155] - M4: An interface between the media access function (412) of the UE (101) and the Media AS (122), which 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).

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

[0157] - 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).

[0158] - 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).

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

[0160] - 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.

[0161] - 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.

[0162] - 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).

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

[0164] 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 Quality of Service (QoS) 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). For 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).

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

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

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

[0168] - Real-Time Communication (RTC): Mutual exchange of media between RTC endpoints. The said RTC endpoints can be UEs or networks.

[0169] 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.

[0170] 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).

[0171] 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.

[0172] Referring to Fig. 5, the media service can be provided to the user through the following procedure.

[0173] 1. Service Provisioning: A media application provider (480) and a Media AF (121) may establish a provisioning session and provision functions for media services. The functions for media services may include dynamic policy invocations, and the provisioning information for setting the dynamic policy invocation functions may include policy template information for dynamic policy invocations. The policy template according to an embodiment of the present disclosure may include media stream identification information.

[0174] 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 (121) to Media AS (122).

[0175] 3. Service Announcement: A media application provider (480) may transmit 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 associated provisioning session identifier and configuration information for dynamic policy requests.

[0176] 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).

[0177] 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.

[0178] 6. Establish Transport Session: A media client (410) and a media AS (121) can establish a media transport session for media transmission. In a real-time communication service, a media transport session can be established between a media client (410) and a terminal participating in another 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 (Uniform Resource Locator) 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., SDP Offer / Answer process) that allow 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 can be determined. For example, when performing media stream filtering using RTP extension headers, the mapping between the Uniform Resource Identifier (URI) and the ID field value of the RTP extension header to be used can be determined at this stage. As another example, when performing media stream filtering using the SSRC field value of the RTP header, the SSRC field value for each media stream can be determined as an SDP parameter at this stage.Additionally, when a media transmission subsession is defined with one or more media streams, a list and / or range of SSRC values ​​of the media streams to be included in the media transmission subsession may be provided as parameters for media stream filtering. An SDP according to an embodiment of the present disclosure may include information for identifying packets belonging to the media transmission subsession and QoS requirements for the media transmission subsession.

[0179] 7. Dynamic policy invocation: A media client (410) may request a dynamic policy setting to be applied to a media transmission session from the 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 transmission subsessions included in a service data flow and / or QoS requirements of the media transmission subsessions. 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.

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

[0181] 9. Confirm QoS Allocation: The media client (410) confirms the result of the dynamic policy setting requested from the Media AF (121). The confirmation message of the policy setting result 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 transmission subsession, etc.).

[0182] 10. Media Contents: The media client (410) can set internal parameters according to the response of the Media AF (121) and start transmitting or receiving media.

[0183] In the above-described embodiment, the media client (410) requests 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).

[0184] 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.

[0185] 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.

[0186] - 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.

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

[0188] - 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.

[0189] - HSS (Home Subscriber Server) (650): The HSS can serve as a database that stores information about users.

[0190] - 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.

[0191] - MRF (Media Resource Function) (670): The MRF can perform various processing tasks related to media streams. The MRF can be divided into the MRFC (Multimedia Resource Function Controller), which is responsible for control, and the MRFP (Multimedia Resource Function Processor), which is responsible for media processing.

[0192] 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.

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

[0194] - 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.

[0195] - 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)).

[0196] - 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)).

[0197] - 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)).

[0198] - 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)).

[0199] - 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).

[0200] - 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).

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

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

[0203] 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).

[0204] 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 the session connection message, accept message, and session update message.

[0205] 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.

[0206] 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. After being proposed as RFC 2543 by the IETF MMUSIC (Multiparty Multimedia Session Control) working group in 1999, revision work was carried out by the separate IETF SIP working group, and the RFC 3261 standard was established in July 2002.

[0207] 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.

[0208] 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 disclosed as Alice's UE and Bob's UE, respectively. However, this is merely an example arbitrarily set to help explain FIG. 7, and Alice and Bob can be replaced with a first user and a second user, Alice's UE and Bob's UE can be replaced with a first UE and a second UE, and the terms referring to the UEs can be replaced with other terms (e.g., a first terminal and a second terminal).

[0209] Referring to FIG. 7, user Alice can use her own UE (or SIP UE) (710) to make a call with Bob's UE (or 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).

[0210] - 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.

[0211] - 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).

[0212] - 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).

[0213] - 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.

[0214] - 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).

[0215] - 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 being performed. 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.

[0216] - 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.

[0217] - 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.

[0218] - 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 SDP 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 an 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).

[0219] - 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 (720) can be identified by the information added to the Via header field in Step 753.

[0220] - 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.

[0221] - 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.

[0222] - 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.

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

[0224] - 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.

[0225] 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, may delete some features and capabilities and transmit them to Bob's proxy server (730), or refuse 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, may delete some features and capabilities and transmit them to Bob's UE (740), or refuse to establish a call session.

[0226] 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.

[0227] 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 above SDP description is shown in [Table 1] below.

[0228] [Table 1]

[0229]

[0230] 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.

[0231] - "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.

[0232] - "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.

[0233] - "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".

[0234] - "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 can be configured in units of media descriptions ("m="row).

[0235] - "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.

[0236] - "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).

[0237] - Media Direction Attribute: The Media Direction Attribute may include "a=recvonly", "a=sendrecv", "a=sendonly", and "a=inactive" attributes. At most one Media Direction Attribute may exist at the session level, and at most one may exist for each media description. If no Media Direction Attribute exists at the session level or the media description level, the "a=sendrecv" attribute may be considered to be applied by default. In the SDP shown in [Table 1] above, the "a=sendrecv" attribute may be applied to the first audio media to indicate that the audio information (audio) described in the corresponding media description is transmitted or received, while the "a=inactive" attribute may be applied to the remaining media descriptions to indicate that the corresponding media (video media) is not transmitted. RTCP packets can be transmitted even when the "a=inactive" attribute is applied.

[0238] When RTCP is used in a media service according to the present disclosure, in the absence of separate signaling, RTCP packets may be transmitted and / or received to a media transmission session having a port number that is the value obtained by adding 1 to the transmission port number used by the RTP stream of the associated media description. For example, in the SDP of [Table 1] above, RTCP packets for voice media transmitted and received at port number 49170 described in the first media description may be transmitted and / or received to a media transmission session with port number 49171. The inclusion of the attribute a=rtcp-mux in the media description may mean that the RTP stream described in the media description and the RTCP packet are transmitted to the same transmission port.

[0239] In order to provide a service (e.g., a real-time communication service) in a wireless communication system according to the present disclosure, there may 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.

[0240] 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.

[0241] 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.

[0242] 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.

[0243] - 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.

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

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

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

[0247] [Table 2]

[0248]

[0249] - 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.

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

[0251] ■ 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))

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

[0253] [Table 3]

[0254]

[0255] - 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.

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

[0257] ■ 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))

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

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

[0260] [Table 4]

[0261]

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

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

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

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

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

[0267] [Table 5]

[0268]

[0269] A media description of an SDP according to the present disclosure may include one or more synchronization source list attributes that provide a list of synchronization sources transmitting media data and / or RTCP packets according to the media parameters described in the media description. When RTCP is used in a media service according to the present disclosure, the synchronization sources transmit RTCP packets and may transmit RTP streams according to the service configuration and / or SDP negotiation results. In the synchronization source list, each synchronization source may be represented by a synchronization source identifier (SSRC value) of the RTP stream and / or RTCP stream transmitted by the synchronization source. The synchronization source list attributes according to the present disclosure may optionally provide the following information for each synchronization source identifier:

[0270] - Media transport subsession identifier to which the referenced synchronization source belongs

[0271] - An indicator showing whether the referenced synchronization source transmits RTP and RTCP packets or only RTCP packets.

[0272] - Whether the synchronization source value is enabled

[0273] For example, the synchronization source list attribute according to the present disclosure may separately provide a list of synchronization sources that transmit both RTP streams and RTCP packets and a list of synchronization sources that transmit only RTCP packets. In this case, the synchronization source list attribute may be expressed as, for example, the Augmented Backus-Naur Form (ABNF) of Table 6 below.

[0274] [Table 6]

[0275]

[0276] In [Table 6] above, the ssrc_id parameter represents an SSRC value as an integer between 0 and (2^32)-1, and the ssrc_list parameter represents one or more ssrc_id parameters separated by commas. The "a=ssrc=list" attribute according to the present disclosure may include a media transmission subsession identifier (subsession_id). The media transmission subsession identifier may be, for example, a string in the form of a string, and if omitted, the first value among the following ssrc_id values ​​may be considered as the transmission subsession identifier. The "a=ssrc-list" attribute according to the present disclosure may include at least one of the ssrc_list parameter following the string "sender=" or the ssrc_list parameter following the string "receiver". At this time, the synchronization source identified by the value of the ssrc_id parameter included in the ssrc_list parameter following the string "sender=" may be a synchronization source that transmits both RTP streams and RTCP packets, and the synchronization source identified by the value of the ssrc_id parameter included in the ssrc_list parameter following the string "receiver=" may be a synchronization source that transmits only RTCP packets.

[0277] For example, the synchronization source list attribute according to the present disclosure may provide a list of synchronization sources that transmit RTCP packets regardless of whether an RTP stream is transmitted. In this case, the synchronization source list attribute may be expressed as ABNF as shown in Table 7 below, for example.

[0278] [Table 7]

[0279]

[0280] In [Table 7] above, the ssrc_id parameter represents an SSRC value as an integer between 0 and (2^32)-1, and the "a=ssrc-list" attribute according to the present disclosure may include one or more ssrc_id parameters separated by commas. The "a=ssrc-list" attribute according to the present disclosure may include a media transmission subsession identifier. The media transmission subsession identifier may be, for example, a string of type string, and if omitted, the first value among the subsequent ssrc_id values ​​may be considered as the transmission subsession identifier.

[0281] For example, the synchronization source list attribute according to the present disclosure may provide a synchronization source list using a separate attribute depending on whether an RTP stream is transmitted. In this case, the synchronization source list attribute that transmits an RTP stream may be represented as ABNF in Table 8 below, for example, and the synchronization source list attribute that does not transmit an RTP stream may be represented as ABNF in Table 9 below, for example.

[0282] [Table 8]

[0283]

[0284] [Table 9]

[0285]

[0286] In [Table 8] above, the ssrc_id parameter represents an SSRC value for transmitting RTP streams and RTCP packets as an integer between 0 and (2^32)-1, and the "a=sender-ssrc-list" attribute according to the present disclosure may include one or more ssrc_id parameters separated by commas. The "a=sender-ssrc-list" attribute according to the present disclosure may include a media transmission subsession identifier. The media transmission subsession identifier may be, for example, a string in string format, and if omitted, the first value among the subsequent ssrc_id values ​​may be considered as the transmission subsession identifier. In [Table 9] above, the ssrc_id parameter represents an SSRC value for transmitting only RTCP packets as an integer between 0 and (2^32)-1, and the "a=receiver-ssrc-list" attribute according to the present disclosure may include one or more ssrc_id parameter values ​​separated by commas. The "a=receiver-ssrc-list" attribute according to the present disclosure may include a media transmission subsession identifier. The media transmission subsession identifier may be, for example, a string of the string format. The media description of the SDP according to the present disclosure may include one "a=sender-ssrc-list" attribute and one "a=receiver-ssrc-list" attribute, each having the same media transmission subsession identifier.

[0287] The synchronization source list attribute of the SDP according to the present disclosure may provide the synchronization source identifier as a list of individual SSRC values ​​or a range of SSRC values. For example, in the embodiment described above, the ssrc_id parameter may be provided in the form of ssrc_min"-ssrc_max, where ssrc_min and ssrc_max are integers between 0 and (2^32)-1 representing the SSRC values, and the ssrc_min value may be smaller than the ssrc_max value.

[0288] At a specific point in time of the real-time communication service according to the present disclosure, any synchronization source identifier included in the synchronization source list attribute may be in an inactive state. The synchronization source identifier in an inactive state may mean a synchronization source identifier that is not referenced in RTP packets and / or RTCP packets, that is, a synchronization source identifier not associated with the synchronization source transmitting the RTP packets and / or RTCP packets. Conversely, a synchronization source identifier in an active state may mean a synchronization source identifier that is referenced in RTP packets and / or RTCP packets, that is, a synchronization source identifier used by the synchronization source transmitting the RTP packets and / or RTCP packets. This means that the synchronization source list attribute of the SDP may include a synchronization source identifier that is in an inactive state at the time of service initiation, and the synchronization source identifier that is in an inactive state at the time of service initiation may be activated during the service or remain in an inactive state until the service ends. In a real-time communication service according to the present disclosure, if a UE and / or network device needs to add a synchronization source after the service has started, the synchronization source may be selected from among the synchronization source identifiers provided in the synchronization source list attribute of the SDP provided by the UE and / or network device during the SDP negotiation process that are currently inactive. The synchronization source identifier included in the synchronization source list of the SDP according to the present disclosure may have a unique value in an RTP session. The RTP session may include one or more media transmission sessions and may refer to a logical unit in which each synchronization source can be identified by a unique SSRC value. In an embodiment of the present disclosure, the synchronization source list attribute of the SDP proposal and the synchronization source list of the SDP response for the same RTP session may have different values ​​during the SDP negotiation process.The synchronization source list attribute of an SDP according to the present disclosure may further include an indicator indicating whether the synchronization source identifier is active at the time the SDP is created or at the time the negotiation is completed. As another example, the active synchronization source identifiers and inactive synchronization source identifiers at the time the SDP is created or at the time the negotiation is completed may be provided as separate synchronization source list attributes.

[0289] A media description of an SDP according to the present disclosure may include a synchronization source QoS requirement attribute that includes QoS requirements for a synchronization source associated with the media description. The synchronization source QoS requirement attribute may include a synchronization source identification parameter and a QoS requirement parameter. The synchronization source identification parameter is information for identifying a synchronization source included in a media transport subsession to which the associated QoS requirement parameter is applied, and may include, for example, one or more SSRC values ​​or a media transport subsession identifier. The QoS requirement parameter may include a QoS requirement to be applied to the media transport subsession referred to by the associated synchronization source identification parameter.

[0290] The above QoS requirements may include, for example, at least one of the following QoS requirement parameters:

[0291] - 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.

[0292] - 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.

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

[0294] - 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.

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

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

[0297] - 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.

[0298] - 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.

[0299] - 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.

[0300] - RTCP Bandwidth: Bandwidth required for RTCP stream transmission. For example, this may be the sum of the bandwidths required by all synchronization sources included in the associated media transmission subsession, and optionally, the ratio of the bandwidths allocated to synchronization sources transmitting RTP streams and synchronization sources transmitting only RTCP streams may be provided together. As another example, the sum of the RTCP bandwidths required by synchronization sources transmitting RTP streams and the sum of the bandwidths required by synchronization sources transmitting only RTCP streams among the synchronization sources included in the associated media transmission subsession may be provided as separate parameters.

[0301] The QoS requirement parameters exemplified above may have common or different values ​​for 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. If the media transmitting subsession refers to the entire synchronization source described in the associated media description, the synchronization source identification parameter of the synchronization source QoS requirement attribute may be omitted or have a value of '*'.

[0302] In a conceptualized media transmission structure according to the present disclosure, a Media AS and / or UE including a signaling server function may identify a synchronization source constituting a media transmission subsession and the QoS requirements of said media transmission subsession from the result of a media parameter negotiation process, and based thereon, provide a Media AF with media transmission subsession packet filtering information capable of identifying packets belonging to said media transmission subsession and the QoS requirements of said media transmission subsession. The Media AF may request a network to provide QoS based on the media transmission subsession packet filtering information and media transmission subsession QoS requirements received from the Media AS and / or UE. The request for QoS provision made by the Media AF to the network may include media transmission subsession packet filtering information and media transmission subsession QoS requirements.

[0303] 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 synchronization source list attribute and / or a synchronization source QoS requirement attribute.

[0304] In an IMS network according to the present disclosure, a P-CSCF may identify the synchronization source constituting the media transport subsession and the QoS requirements of the media transport subsession from the result of the negotiation process (e.g., the SDP Offer / Answer process) and / or from the 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 transport subsession packet filtering information and media transport subsession QoS requirements.

[0305] 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).

[0306] In the media service according to the present disclosure, the RTCP bandwidth included in the media transmission subsession QoS requirements is a value for requesting QoS provision from the network and may be independent of the calculation of the RTCP reporting interval of the synchronization source. In this case, the RTCP reporting interval of the synchronization source may be calculated using the RTCP bandwidth attribute value provided at the media description level.

[0307] In a media service according to the present disclosure, a synchronization source may be modified, added, or removed after the service has been initiated. In this case, a media transport subsession containing or to be containing the modified, added, or removed synchronization source may be signaled by an extension header of an RTP packet and / or an SDES RTCP packet. If a change in the media transport subsession QoS requirements is required due to the modified, added, or removed synchronization source, a media parameter renegotiation and a corresponding QoS request procedure may be initiated.

[0308] Hereinafter, embodiments of the present disclosure are described according to various methods in which a media service provider configures a media service. The following embodiments describe QoS flow mapping and QoS requirements per QoS flow in a wireless network connected to the first UE, under the assumption that the SDP Offer / Answer process is completed based on an SDP offer transmitted by the first UE to the second UE and an SDP response (Answer) transmitted by the second UE to the first UE in response to the SDP offer.

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

[0310] Referring to FIG. 9, the SDP offer (900) of the real-time communication service according to the present disclosure proposes communicating video data encoded with an H.264 codec (see 906) using the RTP / AVPF protocol, using the IP address 198.51.100.1 described in line "c=" (901) and the port number 49220 described in line "m=" (902). At this time, since the SDP offer (900) does not include a media direction attribute, it can be assumed that the attribute "a=sendrecv" is applied as the default value. Additionally, it proposes exchanging RTCP packets in the same media transmission session as the media data using the attribute "a=rtcp-mux" (907). Referring to FIG. 9, the SDP response (950) of the real-time communication service according to the present disclosure communicates video data encoded with an H.264 codec (see 956) using the RTP / AVPF protocol with the IP address 198.51.102.1 described in line "c" (951) and port number 41760 described in line "m" (952), and accepts to exchange RTCP packets (see 957) using the same media transmission session. Thus, the real-time communication service established by the SDP proposal (900) and SDP response (950) exemplified in FIG. 9 can exchange media data in a single RTP session. Furthermore, the resulting media transmission session can be described as follows based on the first UE that transmitted the SDP proposal (900):

[0311] - Uplink Media Transfer Session

[0312] ■ Source IP Address: 198.51.100.1

[0313] ■ Destination IP Address: 198.51.102.1

[0314] ■ Source Port Number: 49220

[0315] ■ Destination Port Number: 41760

[0316] ■ Protocol: UDP

[0317] ■ Application Layer Protocols: RTP & RTCP

[0318] - Downlink media transfer session

[0319] ■ Source IP Address: 198.51.102.1

[0320] ■ Destination IP Address: 198.51.100.1

[0321] ■ Source Port Number: 41760

[0322] ■ Destination Port Number: 49220

[0323] ■ Protocol: UDP

[0324] ■ Application Layer Protocols: RTP & RTCP

[0325] An SDP proposal (900) according to the present disclosure may include attributes indicating requirements for the bandwidth of a media transmission session. Referring to FIG. 9, the "b=AS" attribute (903) may indicate that the bandwidth for media data (RTP / UDP / IP) packet transmission is 2000 kbps, and the "b=RS" attribute (904) and the "b=RR" attribute (905) indicate that the sum of the RTCP bandwidths to be used by synchronization sources transmitting RTP streams is 25 kbps, and the sum of the RTCP bandwidths to be used by synchronization sources transmitting only RTCP streams is 75 kbps, respectively. Referring to FIG. 9, it can be seen that the SDP response (950) accepts the bandwidth requirements of the SDP proposal (900) as they are (953, 954, 955). Accordingly, the required bandwidth for the uplink media transmission session and downlink transmission session of the first UE described above can be set such that the sum of the bandwidth for the media and the bandwidth for RTCP is 2100 kbps, respectively.

[0326] An SDP according to the present disclosure may include a synchronization source list attribute. Referring to FIG. 9, an SDP proposal (900) may propose providing QoS using two media transport subsessions by using the "a=ssrc-list" attribute (908, 909) and the "a=3gpp-qos-ssrc" attribute (910, 911). Referring to the SDP proposal (900) of FIG. 9, the first media transport subsession includes RTP and / or RTCP packets with an identifier value of 'main' and an SSRC value of 1, and the second media transport subsession includes RTP and / or RTCP packets with an identifier value of 'sub' and an SSRC value of 2, 3, or 4. QoS requirements for the 'main' media transmission subsession may be provided by the "a=3gpp-qos-ssrc" attribute (910) in which the synchronization source identification parameter value is 'main', and QoS requirements for the 'sub' media transmission subsession may be provided by the "a=3gpp-qos-ssrc" attribute (911) in which the synchronization source identification parameter value is 'sub'. Referring to the "a=3gpp-qos-ssrc" attribute (910, 911), the RTP bandwidth and RTCP bandwidth of the first media transmission subsession in which the identifier value is 'main' may be 1500 kbps and 25 kbps, respectively, and the RTP bandwidth and RTCP bandwidth of the second media transmission subsession in which the identifier value is 'sub' may be 500 kbps and 75 kbps, respectively.

[0327] Referring to FIG. 9, the SDP response (950) may accept the provision of QoS using two media transport subsessions as proposed in the SDP proposal (900). Referring to the SDP response (950) of FIG. 9, the first media transport subsession (958) contains RTP and / or RTCP packets with an identifier value of 'main' and an SSRC value of 101, and the second media transport subsession (959) contains RTP and / or RTCP packets with an identifier value of 'sub' and an SSRC value of 102, 103, or 104. QoS requirements for the above 'main' media transmission subsession may be provided by the "a=3gpp-qos-ssrc" attribute (961) in which the synchronization source identification parameter value is 'main', and QoS requirements for the above 'sub' media transmission subsession may be provided by the "a=3gpp-qos-ssrc" attribute (962) in which the synchronization source identification parameter value is 'sub'. Referring to the "a=3gpp-qos-ssrc" attribute (961, 962), the RTP bandwidth and RTCP bandwidth of the first media transmission subsession in which the identifier value is 'main' may be 1500 kbps and 25 kbps, respectively, and the RTP bandwidth and RTCP bandwidth of the second media transmission subsession in which the identifier value is 'sub' may be 500 kbps and 75 kbps, respectively. An SDP response according to the present disclosure may include a peer synchronization source mapping attribute (960) representing the relationship between a synchronization source identifier provided as a synchronization source list attribute (958, 959) of the SDP response and a synchronization source identifier provided as a synchronization source list attribute (908, 909) of the associated SDP proposal. The synchronization source mapping attribute (960) may enable mapping between the media transmission subsession of the SDP proposal and the media transmission subsession of the SDP response even when the "a=sscr-list" attribute does not include a media transmission subsession identifier parameter.In addition, in the above-described embodiment, the media transmission subsession of the SDP proposal (900) and the SDP response (950) used the same media transmission subsession identifier, but if the synchronization source mapping attribute (960) exists, the media transmission subsession identifiers of the SDP proposal (900) and the SDP response (950) do not necessarily have to be the same.

[0328] Media transmission subsessions established as a result of SDP negotiation using the SDP proposal (900) and SDP response (950) exemplified in FIG. 9 can be described as shown in the following [Table 10] based on the first UE that transmitted the SDP proposal (900):

[0329] [Table 10]

[0330]

[0331] In the above-described embodiment, the QoS requirement parameters of the associated synchronization source QoS requirement attributes (910 & 961, 911 & 962) in the SDP proposal (900) and SDP response (950) are all shown to be identical, but this may differ depending on the characteristics of the detailed parameters, the policies of the network operator connected to the first UE and the second UE, or the policies of the real-time communication service provider. For example, if the synchronization source QoS requirement parameters of the SDP proposal (900) differ for uplink and downlink, the synchronization source QoS requirement parameters of the associated SDP response (950) may be changed to uplink and downlink QoS requirement parameters based on the second UE. Additionally, if a media processing device exists in the media transmission path between the first UE and the second UE, the synchronization source QoS requirement parameters of the first UE's SDP proposal (900) and the second UE's SDP response (950) may differ.

[0332] When the media description of the SDP according to the present disclosure includes media-level bandwidth requirements, the sum of the bandwidth requirements of the media transmission subsessions included in the media description may be equal to the media-level bandwidth requirements. For example, referring to the SDP proposal (900) of FIG. 9, the "b=AS" attribute (903) of the media description (902) indicates an RTP bandwidth of 2000 kbps, which is equal to the sum of the RTP bandwidth of 1500 kbps of the 'main' media transmission subsession and the RTP bandwidth of 500 kbps of the 'sub' media transmission subsession, which are respectively indicated by the "a=3gpp-qos-ssrc" attributes (910, 911). Additionally, the sum of the "b=RS" attribute (904) and the "b=RR" attribute (905) of the media description (902) represents an RTCP bandwidth of 100 kbps, which is equal to the sum of the RTCP bandwidth of 25 kbps for the 'main' media transmission subsession and the RTCP bandwidth of 75 kbps for the 'sub' media transmission subsession, respectively, represented by the "a=3gpp-qos-ssrc" attributes (910, 911). If the "a=3gpp-qos-ssrc" attributes (910, 911) according to the present disclosure provided the sum of the RTCP bandwidth required by a synchronization source transmitting an RTP stream and the sum of the bandwidth required by a synchronization source transmitting only an RTCP stream as separate parameters when providing RTCP bandwidth, the sum of these may also be equal to the value of the "b=RS" attribute (904) and the value of the "b=RR" attribute (905), respectively. In the above-described embodiment, the RTCP bandwidth of the media transmission subsession was allocated in a ratio of 1:3 based on the assumption that all synchronization sources transmit RTP packets and require the same RTCP bandwidth, but this may be allocated differently depending on the RTCP utilization method of the real-time communication service application.

[0333] FIG. 10 is a diagram illustrating an SDP including QoS requirements per media description according to an embodiment of the present disclosure. Referring to FIG. 10, the "a=group" attribute (1002) having 'BUNDLE' as a semantic parameter value in the SDP proposal (1000) implies that the media descriptions referred to by the media description identifiers following the semantic parameter propose to use the port number proposed in the first media description together. For example, it can be seen that the media description identifiers 'foo' and 'bar' included in the "a=group" attribute (1002) of the SDP proposal (1000) are identical to the "a=mid" attribute (1014) value representing the identifier of the first media description (1010) and the "a=mid" attribute (1014) value representing the identifier of the second media description (1020), respectively. Additionally, when the "a=group" attribute (1002) of the above SDP proposal (1000) is accepted in the SDP response (1050), the second media description (1020), identified by the media description identifier value 'bar' in the above SDP proposal (1000), communicates using the port number 49170 described in the first media description (1010), identified by the media description identifier value 'foo', rather than the port number 49172 described in the SDP proposal (1000). At this time, in order to identify the synchronization source belonging to each media description, the RTP packet may include an extension header containing the "a=mid" attribute (1014) value of the corresponding media description. Additionally, the RTCP packet may include a MID SDES item corresponding to the "a=mid" attribute (1014) value of the corresponding media description.

[0334] Referring to FIG. 10, the SDP proposal (1000) of the real-time communication service according to the present disclosure proposes communicating audio data encoded with an ARM codec (see 1010 hereinafter) and video data encoded with an H.264 codec (see 1020 hereinafter) using the RTP / AVPF protocol, using the IP address 198.51.100.1 described in line "c=" (1001) and the port number 49170 described in line "m=" (1010). For example, since the SDP proposal (1000) does not include a media direction attribute, it can be assumed that the attribute "a=sendrecv" is applied as the default value. Additionally, it proposes exchanging RTCP packets in the same media transmission session as the media data using the attribute "a=rtcp-mux".

[0335] Referring to FIG. 10, the SDP response (1050) of the real-time communication service according to the present disclosure communicates audio data encoded with an ARM codec (see 1060 hereinafter) and video data encoded with an H.264 codec (see 1070 hereinafter) using the RTP / AVPF protocol with the IP address 198.51.102.1 described in line "c=" (1051) and port number 41450 described in line "m=" (1060), and accepts to exchange RTCP packets using the same media transmission session. Accordingly, the real-time communication service established by the SDP proposal (1000) and SDP response (1050) exemplified in FIG. 10 can exchange media data in a single RTP session. Furthermore, the resulting media transmission session can be described as follows based on the first UE that transmitted the SDP proposal (1000):

[0336] - Uplink Media Transfer Session

[0337] ■ Source IP Address: 198.51.100.1

[0338] ■ Destination IP Address: 198.51.102.1

[0339] ■ Source Port Number: 49170

[0340] ■ Destination Port Number: 41450

[0341] ■ Protocol: UDP

[0342] ■ Application Layer Protocols: RTP & RTCP

[0343] - Downlink media transfer session

[0344] ■ Source IP Address: 198.51.102.1

[0345] ■ Destination IP Address: 198.51.100.1

[0346] ■ Source Port Number: 41450

[0347] ■ Destination Port Number: 49170

[0348] ■ Protocol: UDP

[0349] ■ Application Layer Protocols: RTP & RTCP

[0350] An SDP proposal (1000) according to the present disclosure may include attributes indicating requirements for the bandwidth of a media transmission session. Referring to FIG. 10, the "b=AS" attribute (1011) of the first media description (1010) may indicate that the bandwidth for transmitting voice media data (RTP / UDP / IP) packets is 40 kbps, and the "b=RS" attribute (1012) and the "b=RR" attribute (1013) each indicate that the sum of the RTCP bandwidths to be used by synchronization sources transmitting RTP streams is 0.5 kbps and the sum of the RTCP bandwidths to be used by synchronization sources transmitting only RTCP streams is 1.5 kbps. Additionally, the "b=AS" attribute (1021) of the first media description (1020) may indicate that the bandwidth for transmitting video media data (RTP / UDP / IP) packets is 2000 kbps, and the "b=RS" attribute (1022) and the "b=RR" attribute (1023) indicate that the sum of the RTCP bandwidths to be used by synchronization sources transmitting RTP streams is 25 kbps, and the sum of the RTCP bandwidths to be used by synchronization sources transmitting only RTCP streams is 75 kbps, respectively. Referring to FIG. 10, it can be seen that the SDP response (1050) accepts the bandwidth requirements of the SDP proposal (1000) as they are (1061, 1062, 1063, 1071, 1072, 1073). Accordingly, the required bandwidth of the uplink media transmission session and downlink media transmission session of the first UE described above can be set to 2142 kbps, which is the sum of the bandwidth for media and the bandwidth for RTCP. At this time, since the synchronization source transmitting voice data and the synchronization source transmitting video data are synchronization sources of the same RTP session, the available RTCP bandwidth can be calculated using the sum of the "b=RS" and "b=RR" attribute values ​​of all media descriptions belonging to the RTP session, rather than the "b=RS" and "b=RR" attribute values ​​of the associated individual media descriptions.For example, referring to FIG. 10, the bandwidth used by synchronization sources transmitting voice or video RTP packets may be 25.5 kbps, which is the sum of 0.5 kbps, the value of the "b=RS" attribute (1012) of the first description, and 25 kbps, the value of the "b=RS" attribute (1012) of the first description.

[0351] According to the present disclosure, the synchronization source QoS requirement attribute of the SDP may be provided by considering the associated media description as a single media transmission subsession. Referring to FIG. 10, the "a=3gpp-qos-ssrc" attribute (1015) of the first media description (1010) and the "a=3gpp-qos-ssrc" attribute (1025) of the second media description (1020) both have '*' as the synchronization source identification parameter value, which may mean that QoS parameters for all synchronization sources of the respective associated media description are provided. Referring to the "a=3gpp-qos-ssrc" attribute (1015) of the first media description (1010), the RTP bandwidth and RTCP bandwidth of the first media transmission subsession defined by the synchronization sources of the first media description may be 40 kbps and 51 kbps, respectively. Additionally, referring to the "a=3gpp-qos-ssrc" attribute (1025) of the second media description (1020), the RTP bandwidth and RTCP bandwidth of the second media transmission subsession, defined by the synchronization sources of the second media description, may be 2000 kbps and 51 kbps, respectively. In the synchronization source QoS requirement attribute according to one embodiment of the present disclosure, when the media description providing the media description level QoS requirement is considered as a single media transmission subsession, the QoS parameter described in the media description level QoS requirement may be omitted. For example, the bandwidth parameter (bw) may be omitted in the "a=3gpp-qos-ssrc" attributes (1015, 1025) included in the SDP proposal (1000) of FIG. 10. At this time, the UE (101), AS (122), or AF (121) requesting network QoS based on the SDP negotiation result may consider the media level QoS requirements and the QoS requirements provided by the "a=3gpp-qos-ssrc" attribute together.

[0352] Referring to FIG. 10, the SDP response (1050) may accept the provision of QoS using two media transmission subsessions as proposed in the SDP proposal (1000). Referring to the SDP response (1050) of FIG. 10, the first media transmission subsession (1064) may include all synchronization sources of the associated first media description (1060) (synchronization source identification parameter='*'), and the second media transmission subsession (1074) may include all synchronization sources of the associated second media description (1070) (synchronization source identification parameter='*'). Referring to the "a=3gpp-qos-ssrc" attribute (1064) of the first media description (1060), the RTP bandwidth and RTCP bandwidth of the first media transmission subsession may be 40 kbps and 51 kbps, respectively. Additionally, by referring to the "a=3gpp-qos-ssrc" attribute (1074) of the second media description (1070), the RTP bandwidth and RTCP bandwidth of the second media transmission subsession may be 2000 kbps and 51 kbps, respectively.

[0353] Media transmission subsessions established as a result of SDP negotiation using the SDP proposal (100) and SDP response (1050) exemplified in FIG. 10 can be described as shown in the following [Table 11] based on the first UE that transmitted the SDP proposal (1000):

[0354] [Table 11]

[0355]

[0356] In the above-described embodiment, under the assumption that the first UE transmitting the SDP proposal (1000) transmits one voice RTP stream and one video RTP stream, the total RTCP bandwidth of 102 kbps is distributed as 51 kbps each to the synchronization source transmitting voice data belonging to the first media transmission subsession and the synchronization source transmitting video data belonging to the second media transmission subsession, but this can be distributed differently depending on the RTCP utilization method of the real-time communication service application.

[0357] In a wireless communication system according to an embodiment of the present disclosure, a QoS flow may be configured in units of media transmission subsessions. This means that the QoS flow may include one or more media transmission subsessions, and the QoS flow may satisfy the QoS requirements of individual media transmission subsessions.

[0358] FIG. 11 is a drawing illustrating the configuration of a terminal according to one embodiment of the present disclosure.

[0359] A terminal according to one embodiment of the present disclosure may include a processor (1120) that controls the overall operation of the terminal, a transceiver (1100) including a transmitter and a receiver, and a memory (1110). Of course, it is not limited to the examples described above, and the terminal may include more configurations than those shown in FIG. 11, or fewer configurations.

[0360] According to one embodiment of the present disclosure, the transceiver (1100) can transmit and receive signals with network entities or other terminals. The signals transmitted and received with network entities may include control information and data. Additionally, the transceiver (1100) can receive a signal through a wireless channel and output it to a processor (1120), and transmit the signal output from the processor (1120) through a wireless channel.

[0361] According to one embodiment of the present disclosure, the processor (1120) can control the terminal to perform any one of the above-described embodiments. Meanwhile, the processor (1120), memory (1110), and transceiver (1100) are not necessarily implemented as separate modules, and can be implemented as a single component in the form of a single chip. Also, the processor (1120) and the transceiver (1100) can be electrically connected. Additionally, the processor (1120) may include an Application Processor (AP), a Communication Processor (CP), a circuit, an application-specific circuit, a controller, or at least one processor.

[0362] According to one embodiment of the present disclosure, the memory (1110) can store data such as a basic program, an application program, and setting information for the operation of a terminal. In particular, the memory (1110) provides the stored data upon the request of the processor (1120). The memory (1110) may be composed of a storage medium or a combination of storage media such as ROM, RAM, a hard disk, a CD-ROM, and a DVD. Additionally, the memory (1110) may be a plurality of. Furthermore, the processor (1120) may perform the aforementioned embodiments based on a program for performing the aforementioned embodiments of the present disclosure stored in the memory (1110).

[0363] A terminal is an electronic device capable of wireless communication and may include user equipment (UE), mobile phones, smartphones, tablets, Internet of Things (IoT) devices having various form factors, and can perform wireless communication with a base station through a wireless channel.

[0364] Referring to FIG. 11, the terminal may include at least one transceiver (1100) (hereinafter, transceiver), at least one processor (1120) (hereinafter, processor), and at least one memory (1110) (hereinafter, memory). The transceiver (1100), processor (1120), and memory (1110) of the terminal may operate according to at least one or a combination thereof of the methods corresponding to the embodiments of the present disclosure. However, the components of the terminal are not limited to the examples of components shown in FIG. 11. In other embodiments, the terminal may include additional components in addition to the aforementioned components, or some components may be omitted. Also, in some embodiments, any combination of the transceiver (1100), processor (1120), or memory (1110) may be integrated into a single component.

[0365] The transceiver (1100) may be a basic communication circuit or communication circuitry that enables a terminal to perform wireless communication with a node or entity of a network. For example, the transceiver (1100) may enable the terminal to transmit and receive signals with a base station via cellular wireless communication or to transmit and receive signals with another terminal via cellular wireless communication. For example, the transceiver (1100) may be 3G (3rd generation), 4G (4th generation), LTE (long-term evolution), 5G (5th generation), NR (new radio), 6G (6th It can support at least one of various cellular wireless communication technologies including (generation), and the various cellular wireless communication technologies supported by the transceiver (1100) may include all subsequent evolved generations of wireless communication.

[0366] According to one embodiment, the terminal may include a plurality of transceivers, and for example, when supporting EN-DC (E-UTRA (evolved-universal terrestrial radio access) - NR dual connectivity), it may include a first transceiver supporting 4G LTE wireless communication and a second transceiver supporting 5G NR wireless communication. According to another embodiment, when the terminal supports NR-DC (NR Dual Connectivity), the terminal may include a plurality of transceivers supporting 5G NR wireless communication. According to another embodiment, if the terminal supports short-range wireless communication, the terminal may separately include a transceiver that supports at least one of a group of wireless communication protocol standards such as those defined by Bluetooth®, wireless LAN, or a wireless local area network (WLAN) network (including, but not limited to, 802.11ah, 802.11ad, 802.11ay, 802.11ax, 802.11az, 802.11ba, and 802.11be).

[0367] According to one embodiment, the transceiver (1100) may include various circuit structures used to transmit and receive signals through a wireless channel with a base station. The signals may include control information and data. For example, the transceiver (1100) may be configured to include an RF (radio frequency) transmitter that up-converts and amplifies the frequency of a transmitted signal, and an RF receiver that low-noise amplifies a received signal and down-converts the frequency. The transceiver (1100) may output the signal received through the wireless channel to a processor (1120) and transmit the signal output from the processor (1120) through the wireless channel.

[0368] The processor (1120) can control the overall operation of the terminal according to an embodiment of the present disclosure. The processor (1120) may be implemented as one or more IC (integrated circuit (or circuitry)) chips and may perform various data processing operations. The processor (1120) may include at least one electrical circuit and may execute instructions (or programs, code, data, etc.) stored in memory (1110) individually, collectively, or in any combination. Additionally, the processor (1120) may include a single-core processor or a multi-core processor, and in a specific implementation, may be composed of a processor assembly including a plurality of processing circuits.

[0369] The processor (1120) is electrically, operatively, or communicatively coupled to the transceiver (1100) so as to control the transceiver (1100).

[0370] The processor (1120) may include at least one processor (or, processing circuitry), and at least one processor may perform the following operations individually, collectively, or in any combination. For example, the processor (1120) may include a communication processor (CP) that controls communication operations and an application processor (AP) that controls the execution of an upper layer (e.g., an application layer). In a specific embodiment, at least one part of the processor (1120) may be included in one chip, and another part of the processor (1120) may be included in a separate chip. Alternatively, at least one processor may be included in other components, e.g., a transceiver (1100) or a memory (1110).

[0371] The processor (1120) may perform, cause, or control operations of a terminal for performing at least one or a combination of methods according to embodiments of the present disclosure. For example, the processor (1120) may control operations of a terminal for processing downlink signals received from a base station or for generating uplink signals and transmitting them to a base station. To this end, the processor (1120) may control other components of the terminal to perform various operations by executing computer programs, code, or instructions stored in memory (1110).

[0372] Memory (1110) is a hardware storage device capable of storing information temporarily or permanently and may include one or more storage media. For example, memory (1110) may include a memory assembly comprising one or more storage media. For example, the one or more storage media may include a hard drive, flash memory, permanent memory such as ROM (read-only memory), semipermanent memory such as RAM (random access memory), cache memory, or any combination thereof.

[0373] The memory (1110) can be electrically, operatively, or communically coupled with the processor (1120) and can be accessed by the processor (1120).

[0374] A computer program, code, or instruction that can be executed by a processor (1120) may be stored in the memory (1110). According to one embodiment, the computer program, code, or instruction that can be executed by the processor (1120) may be stored in a single memory device or may be separated and distributed across two or more memory devices. The processor (1120) may perform various functions according to the embodiments of the present disclosure by executing the instruction stored in the memory (1110).

[0375] According to one embodiment of the present disclosure, the operation of the terminal may be caused to be performed based on at least one processor (or processing circuit) configured to perform the features of the present disclosure individually, collectively, or in any combination based on the execution of instructions (or computer program or code) stored in memory (1110), based on processing circuitry not configured to execute instructions, and / or based on components of a processing circuitry not configured to execute instructions.

[0376] FIG. 12 is a diagram illustrating the configuration of a base station or network entity according to one embodiment of the present disclosure.

[0377] A network entity according to one embodiment of the present disclosure may include a processor (1220) that controls the overall operation of the network entity, a transceiver (1200) including a transmitter and a receiver, and a memory (1210). Of course, it is not limited to the examples described above, and the network entity may include more configurations than the configuration shown in FIG. 12, or fewer configurations.

[0378] According to one embodiment of the present disclosure, the transmitting and receiving unit (1200) may transmit and receive a signal with at least one of other network entities or terminals. The signal transmitted and received with at least one of other network entities or terminals may include control information and data.

[0379] According to one embodiment of the present disclosure, the processor (1220) can control a network entity to perform any one of the above-described embodiments. Meanwhile, the processor (1220), memory (1210), and transceiver (1200) are not necessarily implemented as separate modules, and can be implemented as a single component in the form of a single chip. Also, the processor (1220) and the transceiver (1200) can be electrically connected. Additionally, the processor (1220) may include an Application Processor (AP), a Communication Processor (CP), a circuit, an application-specific circuit, a controller, or at least one processor.

[0380] According to one embodiment of the present disclosure, the memory (1210) may store data such as a basic program, an application program, and configuration information for the operation of a network entity. In particular, the memory (1210) provides the stored data upon request by the processor (1220). The memory (1210) may be composed of a storage medium or a combination of storage media such as ROM, RAM, a hard disk, a CD-ROM, and a DVD. Additionally, the memory (1210) may be a plurality of. Furthermore, the processor (1220) may perform the aforementioned embodiments based on a program for performing the aforementioned embodiments of the present disclosure stored in the memory (1210).

[0381] A terminal or a base station can perform various communication procedures related to the control plane or user plane by interacting with network entities based on communication through a wireless channel. For example, a terminal can communicate with network entities such as an access and mobility management function (AMF) or a session management function (SMF) through a base station. Alternatively, the base station can perform at least one communication procedure by directly transmitting and receiving signals or relaying them with network entities. The structure of the above-mentioned network entities will be explained in more detail through the drawings below.

[0382] FIG. 13 is a block diagram of a network entity (1300) that performs network functions according to one embodiment of the present disclosure.

[0383] A network entity (1300) may include one or more network functions (NF) that constitute a core network (e.g., 5G (5th generation) core, 5GC) in a communication system, or entities (devices, devices, nodes, or servers, etc.) that perform part of a network function. In this case, multiple NFs may be implemented within a single network entity, or a single NF may be distributed and implemented across multiple network entities. Additionally, when an NF is implemented within a network entity, the NF may be implemented in the form of software, and in such cases, a program for running the NF may be loaded into the memory of the network entity (1300).

[0384] A single NF can be implemented as one or more instances and can operate by being distributed across the same network entity or multiple network entities. Here, the instance is a software unit that logically executes a specific network function and may be separate from physical hardware resources. Additionally, one or more NFs may be implemented as a single network slice to operate in order to satisfy the specifications required by a specific service.

[0385] The above NF may include any one of an access and mobility management function (AMF), a session management function (SMF), a local session management function (L-SMF), a user plane function (UPF), a local user plane function (L-UPF), a policy control function (PCF), unified data management (UDM), a unified data repository (UDR), a network exposure function (NEF), a network repository function (NRF), an application function (AF), a network slice selection function (NSSF), a network data analytics function (NWDAF), a network slice admission control function (NSACF), an authentication server function (AUSF), or a data network (DN).

[0386] Referring to FIG. 13, a network entity (1300) may include at least one network interface (1301), at least one processor (1302) (hereinafter referred to as processor), and at least one memory (1303) (hereinafter referred to as memory). As described above, the NF may be implemented in the form of a physical device such as the network entity (1300), or may be implemented and executed in the form of a virtualized instance. When the NF is implemented in the form of an instance, it may not necessarily include physical components as illustrated in FIG. 13. In such cases, the instance may be composed of one or more logical functional units and may be logically represented.

[0387] According to at least one or a combination thereof of the methods corresponding to the embodiments of the present disclosure, the network interface (1301), processor (1302), and memory (1303) of the network entity (1300) may be operated. However, the components of the network entity (1300) are not limited to the examples of components shown in FIG. 13. In other embodiments, the network entity (1300) may include additional components in addition to the aforementioned components, or some components may be omitted. Also, in one embodiment, the network interface (1301), processor (1302), or memory (1303) may be implemented as a single component.

[0388] The network interface (1301) is a collective term for the transmitting and receiving parts of a network entity and may be a communication circuit for transmitting and receiving signals with a terminal (user equipment, UE), a base station, or other network entities. In this case, the communication circuit may include both a communication circuit for wireless communication and a communication circuit for wired communication. For example, the network interface (1301) may include circuits, logic, hardware, etc. configured to exchange control plane messages or user plane messages with a terminal, a base station, or other core network entities via wireless or wired communication. The network interface (1301) may operate using various protocols (e.g., NAS (Non-Access Stratum) protocol). Depending on the convenience of explanation and technical implementation, the network interface (1301) may be referred to as a communication circuitry, a network interface circuitry, or a communication interface circuitry.

[0389] A processor (1302) may control the overall operation of a network entity (1300) according to an embodiment of the present disclosure. In one embodiment, the processor (1302) may be implemented as one or more IC (integrated circuit or circuitry) chips and may perform various data processing operations. The processor (1302) may include at least one electrical circuit and may execute instructions (or programs, code, data, etc.) stored in memory (1303) individually, collectively, or in any combination. Additionally, the processor (1302) may include a single-core processor or a multi-core processor, and in a specific implementation, may be composed of a processor assembly including a plurality of processing circuits. Additionally, it should be noted that the processor (1302) may not necessarily be composed of physical hardware when the network function (1300) is implemented in an instance form according to another embodiment.

[0390] According to one embodiment, the processor (1302) is electrically, operatively, or communicatively coupled to the network interface (1301) so as to control the network interface (1301).

[0391] The processor (1302) may include at least one processor (or processor circuitry), and at least one processor may perform the following operations individually, collectively, or in any combination. In a particular embodiment, at least one part of the processor (1302) may be included in one chip, and another part of the processor (1302) may be included in a separate chip. Alternatively, at least one processor may be included in other components, such as a network interface (1301) or memory (1303).

[0392] A processor (1302) may perform or control operations of a network entity (1300) to perform at least one or a combination thereof of methods according to embodiments of the present disclosure. For example, the processor (1302) may control operations of the network entity (1300) to exchange control plane messages or user plane messages with terminals, base stations, or other core network entities via wireless or wired communication using various protocols (e.g., NAS protocols). To this end, the processor (1302) may control other components of the network entity (1300) to perform various operations by executing computer programs, code, or instructions stored in memory (1303).

[0393] Memory (1303) is a hardware storage device capable of storing information temporarily or permanently and may include one or more storage media. For example, memory (1303) may include a memory assembly comprising one or more storage media. For example, the one or more storage media may include a hard drive, flash memory, permanent memory such as ROM (read-only memory), semipermanent memory such as RAM (random access memory), cache memory, or any combination thereof.

[0394] According to one embodiment, the memory (1303) may be electrically, operatively, or communicatively coupled to the processor (1302) and may be accessed by the processor (1302).

[0395] A computer program, code, or instruction that can be executed by a processor (1302) may be stored in the memory (1303). According to one embodiment, the computer program, code, or instruction that can be executed by the processor (1302) may be stored in a single memory or separated and distributed across two or more memories. The processor (1302) may perform various functions according to the embodiments of the present disclosure by executing the instruction stored in the memory (1303).

[0396] According to one embodiment of the present disclosure, the operation of a network entity (1300) may be caused to be performed based on at least one processor (or processing circuit) configured to perform the features of the present disclosure individually, collectively, or in any combination based on the execution of instructions (or computer program or code) stored in memory (1303), based on processing circuitry not configured to execute instructions, and / or based on components of a processing circuitry not configured to execute instructions.

[0397] FIG. 14 is a flowchart illustrating an example of a method performed by a first node in one embodiment of the present disclosure.

[0398] In one embodiment of the present disclosure, the first node performing the method (1400) may be a media client (e.g., a terminal) and / or a Media AS.

[0399] In step 1410, the first node may transmit a Session Description Protocol (SDP) offer message containing offer information for at least one media transport subsession to the second node. In one embodiment of the present disclosure, the at least one media transport subsession may include at least one of one or more Real-Time Transport Protocol (RTP) streams or one or more Real-Time Transport Control Protocol (RTCP) streams.

[0400] In one embodiment of the present disclosure, the proposal information for at least one media transmission subsession may include filtering information for at least one media transmission subsession. In one embodiment of the present disclosure, the filtering information may include at least one of SSRC (synchronization source) information or mid attribute information for identifying a stream included in at least one media transmission subsession.

[0401] In one embodiment of the present disclosure, the filtering information may include filtering information corresponding to a first synchronization source group included in a first media transmission subsession and filtering information corresponding to a second synchronization source group included in the first media transmission subsession. The first synchronization source group may include one or more synchronization sources that transmit Real-Time Transport Protocol (RTP) streams, and the second synchronization source group may include one or more synchronization sources that transmit only Real-Time Transport Control Protocol (RTCP) streams.

[0402] In one embodiment of the present disclosure, the proposal information for at least one media transmission subsession may include quality of service (QoS) requirement information for at least one media transmission subsession. In one embodiment of the present disclosure, the QoS requirement information may include Real-Time Transport Control Protocol (RTCP) bandwidth information for at least one media transmission subsession.

[0403] In one embodiment of the present disclosure, RTCP bandwidth information for at least one media transmission subsession may include information on the sum of bandwidths required by one or more synchronization sources included in the second media transmission subsession. In one embodiment of the present disclosure, RTCP bandwidth information for at least one media transmission subsession may include bandwidth ratio information corresponding to a first synchronization source group included in the second media transmission subsession and bandwidth ratio information corresponding to a second synchronization source group included in the second media transmission subsession. The first synchronization source group may include one or more synchronization sources that transmit Real-Time Transport Protocol (RTP) streams, and the second synchronization source group may include one or more synchronization sources that transmit only RTCP streams.

[0404] In one embodiment of the present disclosure, RTCP bandwidth information for at least one media transmission subsession may include bandwidth information assigned to a first synchronization source group included in a third media transmission subsession and bandwidth information assigned to a second synchronization source group included in the third media transmission subsession. The first synchronization source group may include one or more synchronization sources that transmit Real-Time Transport Protocol (RTP) streams, and the second synchronization source group may include one or more synchronization sources that transmit only RTCP streams.

[0405] In step 1420, the first node may receive an SDP answer message from the second node containing information indicating whether to accept the proposal information.

[0406] In one embodiment of the present disclosure, a media transmission session between a first node and a second node may be established based on information indicating whether the proposal information is accepted.

[0407] FIG. 15 is a flowchart illustrating an example of a method performed by a second node in one embodiment of the present disclosure.

[0408] In one embodiment of the present disclosure, the second node performing the method (1400) may be a media client (e.g., a terminal) and / or a Media AS.

[0409] In step 1510, the second node may receive a Session Description Protocol (SDP) offer message from the first node containing offer information for at least one media transport subsession. In one embodiment of the present disclosure, the at least one media transport subsession may include at least one of one or more Real-Time Transport Protocol (RTP) streams or one or more Real-Time Transport Control Protocol (RTCP) streams.

[0410] In one embodiment of the present disclosure, the proposal information for at least one media transmission subsession may include filtering information for at least one media transmission subsession. In one embodiment of the present disclosure, the filtering information may include at least one of SSRC (synchronization source) information or mid attribute information for identifying a stream included in at least one media transmission subsession.

[0411] In one embodiment of the present disclosure, the filtering information may include filtering information corresponding to a first synchronization source group included in a first media transmission subsession and filtering information corresponding to a second synchronization source group included in the first media transmission subsession. The first synchronization source group may include one or more synchronization sources that transmit Real-Time Transport Protocol (RTP) streams, and the second synchronization source group may include one or more synchronization sources that transmit only Real-Time Transport Control Protocol (RTCP) streams.

[0412] In one embodiment of the present disclosure, the proposal information for at least one media transmission subsession may include quality of service (QoS) requirement information for at least one media transmission subsession. In one embodiment of the present disclosure, the QoS requirement information may include Real-Time Transport Control Protocol (RTCP) bandwidth information for at least one media transmission subsession.

[0413] In one embodiment of the present disclosure, RTCP bandwidth information for at least one media transmission subsession may include information on the sum of bandwidths required by one or more synchronization sources included in the second media transmission subsession. In one embodiment of the present disclosure, RTCP bandwidth information for at least one media transmission subsession may include bandwidth ratio information corresponding to a first synchronization source group included in the second media transmission subsession and bandwidth ratio information corresponding to a second synchronization source group included in the second media transmission subsession. The first synchronization source group may include one or more synchronization sources that transmit Real-Time Transport Protocol (RTP) streams, and the second synchronization source group may include one or more synchronization sources that transmit only RTCP streams.

[0414] In one embodiment of the present disclosure, RTCP bandwidth information for at least one media transmission subsession may include bandwidth information assigned to a first synchronization source group included in a third media transmission subsession and bandwidth information assigned to a second synchronization source group included in the third media transmission subsession. The first synchronization source group may include one or more synchronization sources that transmit Real-Time Transport Protocol (RTP) streams, and the second synchronization source group may include one or more synchronization sources that transmit only RTCP streams.

[0415] In step 1520, the second node may transmit an SDP answer message to the first node containing information indicating whether to accept the proposal information. In one embodiment of the present disclosure, a media transmission session between the first node and the second node may be established based on the information indicating whether to accept the proposal information.

[0416] In one embodiment of the present disclosure, a method performed by a first node in a wireless communication system may include the step of transmitting a Session Description Protocol (SDP) offer message to a second node that includes offer information for at least one media transmission subsession. In one embodiment of the present disclosure, a method performed by a first node in a wireless communication system may include the step of receiving an SDP answer message from the second node that includes information indicating whether to accept the offer information. In one embodiment of the present disclosure, a media transmission session between the first node and the second node may be established based on the information indicating whether to accept the offer information.

[0417] In one embodiment of the present disclosure, a method performed by a second node in a wireless communication system may include the step of receiving a Session Description Protocol (SDP) offer message from a first node that includes offer information for at least one media transmission subsession. In one embodiment of the present disclosure, a method performed by a second node in a wireless communication system may include the step of transmitting an SDP answer message to the first node that includes information indicating whether to accept the offer information. In one embodiment of the present disclosure, a media transmission session between the first node and the second node may be established based on the information indicating whether to accept the offer information.

[0418] In one embodiment of the present disclosure, a first node in a wireless communication system may include at least one transceiver, at least one processor connected to at least one transceiver, and at least one memory connected to at least one processor. In one embodiment of the present disclosure, at least one memory may store an instruction executable by at least one processor that causes the first node to transmit a Session Description Protocol (SDP) offer message containing offer information for at least one media transmission subsession to a second node. In one embodiment of the present disclosure, at least one memory may store an instruction executable by at least one processor that causes the first node to receive an SDP answer message containing information indicating whether to accept the offer information from the second node. In one embodiment of the present disclosure, a media transmission session between the first node and the second node may be established based on information indicating whether to accept the offer information.

[0419] In one embodiment of the present disclosure, a second node in a wireless communication system may include at least one transceiver, at least one processor connected to at least one transceiver, and at least one memory connected to at least one processor. In one embodiment of the present disclosure, at least one memory may store an instruction executable by at least one processor that causes the second node to receive a Session Description Protocol (SDP) offer message containing offer information for at least one media transmission subsession from a first node. In one embodiment of the present disclosure, at least one memory may store an instruction executable by at least one processor that causes the second node to transmit an SDP answer message containing information indicating whether to accept the offer information to the first node. In one embodiment of the present disclosure, a media transmission session between the first node and the second node may be established based on information indicating whether to accept the offer information.

[0420] In one embodiment of the present disclosure, at least one media transmission subsession may include at least one of one or more Real-Time Transport Protocol (RTP) streams or one or more Real-Time Transport Control Protocol (RTCP) streams.

[0421] In one embodiment of the present disclosure, the proposal information for at least one media transmission subsession may include filtering information for at least one media transmission subsession. In one embodiment of the present disclosure, the filtering information may include at least one of SSRC (synchronization source) information or mid attribute information for identifying a stream included in at least one media transmission subsession.

[0422] In one embodiment of the present disclosure, the filtering information may include filtering information corresponding to a first synchronization source group included in a first media transmission subsession and filtering information corresponding to a second synchronization source group included in the first media transmission subsession. The first synchronization source group may include one or more synchronization sources that transmit Real-Time Transport Protocol (RTP) streams, and the second synchronization source group may include one or more synchronization sources that transmit only Real-Time Transport Control Protocol (RTCP) streams.

[0423] In one embodiment of the present disclosure, the proposal information for at least one media transmission subsession may include quality of service (QoS) requirement information for at least one media transmission subsession. In one embodiment of the present disclosure, the QoS requirement information may include Real-Time Transport Control Protocol (RTCP) bandwidth information for at least one media transmission subsession.

[0424] In one embodiment of the present disclosure, RTCP bandwidth information for at least one media transmission subsession may include information on the sum of bandwidths required by one or more synchronization sources included in the second media transmission subsession. In one embodiment of the present disclosure, RTCP bandwidth information for at least one media transmission subsession may include bandwidth ratio information corresponding to a first synchronization source group included in the second media transmission subsession and bandwidth ratio information corresponding to a second synchronization source group included in the second media transmission subsession. The first synchronization source group may include one or more synchronization sources that transmit Real-Time Transport Protocol (RTP) streams, and the second synchronization source group may include one or more synchronization sources that transmit only RTCP streams.

[0425] In one embodiment of the present disclosure, RTCP bandwidth information for at least one media transmission subsession may include bandwidth information assigned to a first synchronization source group included in a third media transmission subsession and bandwidth information assigned to a second synchronization source group included in the third media transmission subsession. The first synchronization source group may include one or more synchronization sources that transmit Real-Time Transport Protocol (RTP) streams, and the second synchronization source group may include one or more synchronization sources that transmit only RTCP streams.

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

[0427] It should be noted that the aforementioned configuration diagrams, exemplary diagrams of control / data signal transmission methods, exemplary diagrams of operation procedures, and configuration diagrams are not intended to limit the scope of the rights of the present disclosure. That is, all components, entities, or steps of operation described in the embodiments of the present disclosure should not be interpreted as essential components for the implementation of the disclosure, and may be implemented within a scope that does not impair the essence of the disclosure even if only some components are included. Furthermore, each embodiment may be combined and operated as needed. For example, parts of the methods proposed in the present disclosure may be combined to operate network entities and terminals.

[0428] 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.

[0429] 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.

[0430] 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.

[0431] 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.

[0432] 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.

[0433] 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.

[0434] 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.

[0435] 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.

[0436] 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.

[0437] 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.

[0438] 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).

[0439] 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.

[0440] 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.

[0441] 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.

[0442] 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.

Claims

1. A method performed by a first node in a wireless communication system, A step of transmitting a Session Description Protocol (SDP) offer message containing offer information for at least one media transmission subsession to a second node; and The method includes the step of receiving an SDP answer message from the second node containing information indicating whether the proposal information is accepted, and A method in which a media transmission session is established between a first node and a second node based on information indicating whether the above proposal information is accepted.

2. In Paragraph 1, A method wherein the above-mentioned at least one media transmission subsession comprises at least one of one or more Real-Time Transport Protocol (RTP) streams or one or more Real-Time Transport Control Protocol (RTCP) streams.

3. In Paragraph 1, A method in which the proposal information for at least one media transmission subsession includes filtering information for at least one media transmission subsession.

4. In Paragraph 3, A method wherein the filtering information comprises at least one of SSRC (synchronization source) information or mid attribute information for identifying a stream included in at least one media transmission subsession.

5. In Paragraph 3, The filtering information includes filtering information corresponding to a first synchronization source group included in a first media transmission subsession and filtering information corresponding to a second synchronization source group included in the first media transmission subsession. The first synchronization source group includes one or more synchronization sources that transmit Real-Time Transport Protocol (RTP) streams, and A method in which the second synchronization source group comprises one or more synchronization sources that transmit only RTCP (Real-Time Transport Control Protocol) streams.

6. In Paragraph 1, A method in which the proposal information for at least one media transmission subsession includes quality of service (QoS) requirement information for at least one media transmission subsession.

7. In Paragraph 6, A method wherein the above QoS requirement information includes RTCP (Real-Time Transport Control Protocol) bandwidth information for at least one media transmission subsession.

8. In Paragraph 7, A method wherein RTCP bandwidth information for at least one media transmission subsession includes information on the sum of bandwidths required by one or more synchronization sources included in the second media transmission subsession.

9. In Paragraph 8, RTCP bandwidth information for at least one media transmission subsession further includes bandwidth ratio information corresponding to a first synchronization source group included in the second media transmission subsession and bandwidth ratio information corresponding to a second synchronization source group included in the second media transmission subsession. The first synchronization source group includes one or more synchronization sources that transmit Real-Time Transport Protocol (RTP) streams, and A method in which the second synchronization source group comprises one or more synchronization sources that transmit only RTCP streams.

10. In Paragraph 7, RTCP bandwidth information for at least one media transmission subsession includes bandwidth information assigned to a first synchronization source group included in the third media transmission subsession and bandwidth information assigned to a second synchronization source group included in the third media transmission subsession. The first synchronization source group includes one or more synchronization sources that transmit Real-Time Transport Protocol (RTP) streams, and A method in which the second synchronization source group comprises one or more synchronization sources that transmit only RTCP streams.

11. A method performed by a second node in a wireless communication system, A step of receiving a Session Description Protocol (SDP) offer message containing offer information for at least one media transmission subsession from a first node; and The method includes the step of transmitting an SDP answer message to the first node containing information indicating whether the proposal information is accepted, and A method in which a media transmission session is established between a first node and a second node based on information indicating whether the above proposal information is accepted.

12. In Paragraph 11, A method wherein the above-mentioned at least one media transmission subsession comprises at least one of one or more Real-Time Transport Protocol (RTP) streams or one or more Real-Time Transport Control Protocol (RTCP) streams.

13. In Paragraph 11, A method wherein the proposal information for the at least one media transmission subsession comprises at least one of filtering information or quality of service (QoS) requirement information for the at least one media transmission subsession.

14. In a first node of a wireless communication system, At least one transmitting and receiving unit; At least one processor connected to the above at least one transmitting and receiving unit; and It includes at least one memory connected to the above at least one processor, and The above at least one memory is, the first node, Transmit a Session Description Protocol (SDP) offer message containing offer information for at least one media transmission subsession to the second node, and Storing an instruction executable by the at least one processor, which receives an SDP answer message containing information indicating whether the proposal information is accepted from the second node, and A first node in which a media transmission session between the first node and the second node is established based on information indicating whether the above proposal information is accepted.

15. In a second node in a wireless communication system, At least one transmitting and receiving unit; At least one processor connected to the above at least one transmitting and receiving unit; and It includes at least one memory connected to the above at least one processor, and The above at least one memory is, the above second node, Receive a Session Description Protocol (SDP) offer message containing offer information for at least one media transmission subsession from a first node, and Storing an instruction executable by the at least one processor, which transmits an SDP answer message containing information indicating whether the proposal information is accepted to the first node, and A second node in which a media transmission session between the first node and the second node is established based on information indicating whether the above proposal information is accepted.

Images