Method and apparatus for protocol data unit set-based real-time transmission control protocol sender report

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. In addition, the present disclosure relates to a user equipment for supporting a real-time communication service in a wireless communication system. A method of a user equipment for supporting a real-time communication service in a wireless communication system, according to the present disclosure, may comprise the steps of: receiving media-specific importance-related information from a media transmission apparatus; responding to packet loss by using the received media-specific importance-related information; and providing the media-specific importance-related information to a network.

Description

Protocol Data Unit Set-Based Real-Time Transmission Control Protocol Sender Reporting Method and Device

[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 method and apparatus for responding to network congestion and packet loss in a wireless communication system.

[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) for supporting new services through linkage and convergence with other industries, Integrated Access and Backhaul (IAB) which provides nodes for expanding 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 (2-step RACH 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) for incorporating 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 media data in various formats (e.g., graphical objects, audio, video, haptic) in real time is a prerequisite. Prior to transmission over a network, the aforementioned various media data formats can be encoded using a codec suited to the characteristics of each medium. In this process, each packet containing the encoded media data may have different levels of importance depending on the characteristics of the codec. Reflecting this, discussions are ongoing regarding how to respond to network congestion or packet loss by considering the importance of the packets.

[0009] One objective of the present disclosure is to provide a method for prioritizing the processing of packets of high media importance when network congestion and / or packet loss occur in a mobile communication system.

[0010] In addition, one object of the present disclosure is to provide a method and apparatus for providing a packet distribution by importance of each media and / or an importance threshold for media playback to a network device and / or user device for importance-based packet processing.

[0011] In addition, one objective of the present disclosure is to provide a method and apparatus for providing a packet distribution by importance according to a resource allocation unit of a network to a network device for importance-based packet processing.

[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] A method of a user device for supporting a real-time communication service in a mobile communication system according to one embodiment of the present disclosure for solving the above-mentioned problems may include: receiving information regarding media-specific importance from a media transmitting device; responding to packet loss using the received information regarding media-specific importance; and providing information regarding media-specific importance to a network.

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

[0015] Existing network congestion and packet loss management methods that do not consider the relative importance of packets have a problem in that they cannot optimize media playback quality relative to network usage because they cannot predict the impact of lost packets on media playback quality.

[0016] According to one example of the present disclosure, a media transmission device (e.g., a user device or a network server) may provide media-specific importance information to a media receiving device (e.g., a user device or a network server). The media receiving device may use the media-specific importance information to request the media transmission device to retransmit packets that are determined to have high importance among the lost packets.

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

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

[0019] FIG. 2 is a diagram illustrating the concept of the packetization process of an image data unit in a wireless communication system according to the present disclosure.

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

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

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

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

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

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

[0026] FIG. 9 is a diagram of user equipment according to one embodiment of the present disclosure.

[0027] FIG. 10 is a diagram of a network entity according to one embodiment of the present disclosure.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0050] The present disclosure relates to a method and apparatus for handling network congestion and / or packet loss when such occurs in a mobile communication system. For example, the present disclosure relates to a method and apparatus for optimizing media playback quality relative to network resources in a media service including a Real-Time Communication Service and a Media Streaming Service.

[0051] Real-time communication services may consist of media having various transmission characteristics, such as voice, video, and text. To guarantee QoS for real-time communication services, a network may consider information for identifying packets containing the media data and transmission characteristics specific to each media. A general communication system defines a packet flow, which is a set of packets to which the same QoS is provided, and configures the behavior of network entities located in the communication path of the media session. The information for configuring the behavior of the network entities may include information for identifying packets belonging to the packet flow and QoS policies to be applied to the packets belonging to the packet flow. The information for identifying the packet flow includes the sending and receiving IP addresses, sending and receiving port numbers (e.g., TCP or UDP port numbers), and transmission protocol identifiers. For example, in a real-time communication service including voice and video, if the uninterrupted delivery of voice information is critical, the voice information may be transmitted via a separate packet flow that provides a higher QoS.

[0052] Data units constituting media may have different levels of importance and interrelationships depending on the characteristics of the media. For example, in video compression, an intra-frame can affect the restoration of other frames that reference it. Additionally, data units constituting media data may not be preserved during the packetization process for network transmission and may be divided into multiple packets. Therefore, if packets containing the intra-frame are processed to have a higher priority than packets containing frames that reference the intra-frame, network resources can be utilized efficiently. To solve the aforementioned problems, the present disclosure provides a method for processing media packets by considering the importance of the media data contained in the packet.

[0053] The apparatus and method according to the various embodiments of the present disclosure described below enable real-time communication service providers to prioritize the processing of packets of high importance in terms of media when network congestion and / or packet loss occur when providing real-time services in a 5GS (5G system).

[0054] The effects obtainable from the present disclosure are not limited to those mentioned above, and other unmentioned effects will be clearly understood by those skilled in the art to which the present disclosure belongs from the description below.

[0055] In addition, for the convenience of explanation, terms and names defined in the specifications for 5G systems are used in the following description. However, the present disclosure is not limited by the terms and names described above and may be equally applied to systems conforming to other specifications.

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

[0057] 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 one VNF providing services to other VNFs through RESTful-based API exchanges. An API-based communication interface between VNFs is called a Service Based Interface (SBI).

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

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

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

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

[0062] The AF (121) according to the present disclosure can provide media-specific importance-related information to the PCF device (113) directly or through a network exposure function (NEF) device (114).

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

[0064] As described above, the data units constituting the media data are not preserved during the packetization process for network transmission and can be divided into multiple packets.

[0065] FIG. 2 is a conceptual diagram illustrating the packetization process of an image data unit in a wireless communication system according to the present disclosure. General image data may be composed of a group of pictures (GOP; Group of Picture) including images such as an I image (Intra-coded picture), a P image (Predictive-coded picture), and a B image (bidirectional-coded picture), and the group of pictures may include at least one I image.

[0066] Referring to FIG. 2, a set of images may consist of one I-frame (210), two B-frames (220, 230), and one P-frame (240), and the I-frame (210) may be divided into four payloads, PL1 (211), PL2 (212), PL3 (213), and PL4 (214), and transmitted as four packets (261, 262, 263, 264) each containing a payload. Subsequently, a set of payloads divided from a single media data unit may be referred to as a PDU Set. Referring to FIG. 2, the four payloads, PL1 (211), PL2 (212), PL3 (213), and PL4 (214), that make up the I frame (210) form one PDU Set, and the two payloads, PL1 (241) and PL (242), that make up the P frame (240) form another PDU Set.

[0067] The above packet consists of a header and a payload, wherein the header may include information necessary for the network to process the packet and transmit it to a destination, and the payload may include information necessary for the receiving end to process media data and may include a separate payload header according to the media data processing method. The network may utilize the data included in the packet header and payload to identify the packet.

[0068] When a network identifies packets containing PDUs belonging to the same PDU Set, packet processing can be performed based on said PDU Set. For example, packet loss may occur when the traffic volume exceeds the network's processing capacity. In this case, the degradation of service quality can be minimized by prioritizing the processing of packets belonging to PDU Sets with high importance. Network equipment supporting the above PDU Set importance-based packet processing may be required to have the function of identifying packets belonging to the same PDU Set and the function of identifying the importance of said PDU Set.

[0069] In a real-time communication service according to the present disclosure, a media receiving device may identify a lost packet and request a media transmitting device to retransmit it. If the media receiving device requests retransmission based on the importance of the PDU Set to which the lost packet belongs, the maximum improvement in media playback quality relative to network usage can be obtained. At this time, the media receiving device may be required to have a function for estimating the importance of the lost packet and a function for determining whether to request retransmission based on the estimated importance.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0089] A media service according to the present disclosure may include one or more media transport sessions, and the media transport sessions may be identified by a 5-tuple (source IP address, destination IP address, source port number, destination port number, transport protocol). Accordingly, 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.

[0090] Information for identifying packets belonging to the above PDU Set and information regarding importance to be applied to packets belonging to the above PDU Set can be transmitted to network equipment through packet headers and PDUs. A media transmission session according to an embodiment of the present disclosure may transmit said information using packet headers and payload headers. The specific formats of the headers and payloads used to transmit said information, and the information included in said headers and payloads, may vary depending on the type of protocol used in said media transmission session and the profile operating said protocol. Hereinafter, the method used to transmit information related to the PDU Set in said media transmission session may be referred to as the PDU Set Marking method. The PDU Set Marking method according to an embodiment of the present disclosure may include an RTP extension header. Furthermore, said PDU Set Marking method may be included in network configuration information that supports PDU Set-based packet processing.

[0091] A media transmitting device according to the present disclosure may use RTCP to provide media-specific importance-related information. The media-specific importance-related information may include packet transmission statistics by importance and / or thresholds of importance values ​​required for media playback. The packet transmission statistics by importance may have approximate estimates determined by the media codec and encoding parameters used. A media transmitting device according to the present disclosure may use SDP to provide the packet transmission statistics estimates and / or thresholds of importance values ​​required for media playback. A media transmitting device and / or a media receiving device according to the present disclosure may provide the packet transmission statistics estimates and / or thresholds of importance values ​​required for media playback described in the SDP to a network via AF (121).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0114] 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). As another example, it may subscribe to a network event notification service and receive notifications when an associated situation occurs on the network. The above event notification can be transmitted directly to the Media AF (121) from the network function associated with the event (e.g., PCF (113) or UPF (103)) or transmitted via the NEF (114).

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

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

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

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

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

[0120] In a conceptualized media transmission structure according to the present disclosure, the Media AF (121) may receive information regarding the PDU Set Marking method and / or information regarding media-specific importance from the media application provider (480). In a conceptualized media transmission structure according to the present disclosure, the Media AF (121) may receive information regarding the PDU Set Marking method and / or information regarding media-specific importance 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 information regarding the PDU Set Marking method and / or information regarding media-specific importance to the PCF device (113) directly or via the NEF device (114) based on information obtained from the media application provider (480), the UE (101), and / or the Media AS (122). The above PCF device (113), SMF device (112), or AMF device (111) can integrate and provide information regarding the importance of each media for the media transmitted via the QoS flow based on the QoS flow.

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

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

[0123] 1. Service Provisioning: A media application provider (480) and a Media AF (121) can establish a provisioning session and perform function settings for a media service. The function for the media service may include a dynamic policy invocation, and the provisioning information for setting the dynamic policy invocation function may include policy template information for the dynamic policy invocation. The policy template according to an embodiment of the present disclosure may include media stream identification information.

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

[0125] 3. Service Announcement: A media application provider (480) may deliver service announcement information to a media awareness application (420) running on a user device (UE). The service announcement information may include service access information or a path to obtain service access information. The service access information may include an associated provisioning session identifier and configuration information for dynamic policy requests.

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

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

[0128] 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, the media transport session can be established between the 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 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 media data is exchanged using the RTP protocol, detailed parameters for providing information regarding PDU Set Marking and media-specific importance may be determined. For example, when transmitting information regarding PDU Set using an RTP extension header, the mapping between the URI and ID field values ​​of the RTP extension header to be used may be determined at this stage. For example, when information regarding media-specific importance is provided using RTCP, parameters related to RTCP message transmission may be determined at this stage. Additionally, the SDP according to the present disclosure may include attributes indicating packet transmission statistics estimates and / or thresholds of importance values ​​that are essential for media playback.

[0129] 7. Dynamic policy invocation: A media client (410) may request a media AF (121) to set a dynamic policy to be applied to a media transmission session. The request for a dynamic policy setting 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 related to PDU Set Marking and / or information related to media importance. Detailed parameters of the request for a dynamic policy setting according to an embodiment of the present disclosure may be determined in the media-related detailed parameter negotiation step of step 6.

[0130] 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 related to PDU Set Marking and / or information related to media importance, along with QoS requirements.

[0131] 9. Confirm QoS Allocation: The media client (410) checks the result of the dynamic policy setting requested from the Media AF (121). The policy setting result confirmation message may include information about the dynamic policy setting status (e.g., Accepted, Rejected, etc.) and instructions for the dynamic policy (e.g., bit rate, etc.).

[0132] 10. Media Contents: A media client (410) may set internal parameters in response to the Media AF (121) and initiate media transmission or reception. At this time, RTCP packets according to the present disclosure may be transmitted according to transmission parameters set during the SDP negotiation process. Additionally, in the event of network congestion and / or packet loss, packet processing considering media importance according to the present disclosure may be applied to the media packets.

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

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

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

[0136] - 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 information related to PDU set marking and / or media importance based on SDP parameters included in SIP messages and / or network operator policies, along with QoS requirements, to the PCF (113).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0178] v=0o=alice 2819384758 2819384758 IN IP4 198.51.100.1s=Call to Bobc=IN IP4 198.51.100.1t=0 0a=inactivem=audio 49170 RTP / AVP 97a=sendrecva=rtpmap:97 AMR / 8000 / 1m=video 51372 RTP / AVP 99a=rtpmap:99 H264 / 90000

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

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

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

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

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

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

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

[0186] - 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 described in that media description is being transmitted, while the "a=inactive" attribute may be applied to the remaining media descriptions to indicate that the corresponding media (video media) is not being transmitted. RTCP packets can be transmitted even when the "a=inactive" attribute is applied.

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

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

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

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

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

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

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

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

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

[0196] v=0o=alice 2890844526 2890844526 IN IP4 198.51.100.1s=c=IN IP4 198.51.100.1t=0 0m=audio 49170 RTP / AVP 0a=rtpmap:0 PCMU / 8000m=video 51372 RTP / AVP 31a=rtpmap:31 H261 / 90000m=video 53000 RTP / AVP 32a=rtpmap:32 MPV / 90000

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

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

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

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

[0201] v=0o=bob 2890844730 2890844730 IN IP4 198.51.100.2s=c=IN IP4 198.51.100.2t=0 0m=audio 49920 RTP / AVP 0a=rtpmap:0 PCMU / 8000m=video 0 RTP / AVP 31m=video 53000 RTP / AVP 32a=rtpmap:32 MPV / 90000

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

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

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

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

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

[0207] v=0o=bob 2890844730 2890844731 IN IP4 198.51.100.2s=c=IN IP4 198.51.100.2t=0 0m=audio 65422 RTP / AVP 0a=rtpmap:0 PCMU / 8000m=video 0 RTP / AVP 31m=video 53000 RTP / AVP 32a=rtpmap:32 MPV / 90000m=audio 51434 RTP / AVP 110a=rtpmap:110 telephone-events / 8000a=recvonly

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

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

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

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

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

[0213] v=0o=alice 2890844526 2890844527 IN IP4 198.51.100.1s=c=IN IP4 198.51.100.1t=0 0m=audio 49170 RTP / AVP 0a=rtpmap:0 PCMU / 8000m=video 0 RTP / AVP 31a=rtpmap:31 H261 / 90000m=video 53000 RTP / AVP 32a=rtpmap:32 MPV / 90000m=audio 53122 RTP / AVP 110a=rtpmap:110 telephone-events / 8000a=sendonly

[0214] Information related to a PDU Set included in a media transmission session according to an embodiment of the present disclosure may be configured as follows.

[0215] - PDU Set Identification Information

[0216] ■ PDU Set Sequence Number: Sequence number of the PDU Set, unsigned integer

[0217] ■ Start / End PDU of the PDU Set: The first and last PDUs in the PDU Set. They may be signaled by a separate flag with a Boolean value, or indirectly signaled through the PDU SN and the number of PDUs in the PDU Set described later.

[0218] ■ PDU SN within a PDU Set: Serial number of a PDU in a PDU Set, unsigned integer

[0219] ■ Number of PDUs within a PDU Set: Number of PDUs in a PDU Set

[0220] - PDU Set processing information

[0221] ■ PDU Set importance: The importance of a PDU Set. An unsigned integer. For example, it can be a value between 0 and 15, and the smaller the number, the higher the importance. A value of 0 can be used when the media transmitting device cannot determine the importance.

[0222] ■ PDU Set dependency: The dependency relationship between PDU Sets. Can be signaled by a list of PDU Set sequence numbers or the number of dependent PDU Sets.

[0223] ■ PDU Set period: The duration / period of a PDU Set. A single PDU Set can be signaled within a time-window, at a fixed period, or in milliseconds.

[0224] ■ PDU Set loss tolerance: The allowable loss limit of a PDU Set, an unsigned integer. If the value is 0, the entire PDU Set may not be usable by the application layer if even one of the PDUs in the PDU Set is lost.

[0225] ■ PDU Set delay / jitter sensitivity: Delay and jitter sensitivity, unsigned integer. A value of 0 allows for retransmission.

[0226] In the PDU Set Marking according to the present disclosure, the PDU Set Sequence Number may be set at the level of a media transmission session or an RTP session including one or more media transmission sessions. This means that when the PDU Set Sequence Number of the PDU Set currently being transmitted is K based on one RTP stream, the PDU Set Sequence Number of the PDU Set to be transmitted subsequently may be a value greater than K but not K+1.

[0227] The PDU Set Marking method is a technique for transmitting PDU Set-related information to network equipment or the application layer. It may consist of in-band information, which is recorded in a packet using headers, extension headers, and payload headers of higher-layer transport protocols, and out-band information, which is transmitted via a separate data structure. For example, the PDU Set identification information may be in-band information. The PDU Set processing information may be out-band information or a combination of in-band and out-band information. The out-band information may be transmitted as 5G control plane signaling information or as a message from a media session control protocol such as SIP or SDP. The out-band information may be transmitted to the UPF via the PCF as detailed parameters of the PDU Set Marking method.

[0228] A media transmitting device according to the present disclosure may generate a PDU Set-based RTCP sender report and transmit it to a media receiving device. In the present disclosure, a PDU Set-based RTCP sender report may include at least one of the following information along with a Synchronization Source Identifier (SSRC) value that transmits an associated media stream:

[0229] - Packet transmission statistics by importance

[0230] - Threshold of importance value essential for media playback

[0231] Packet transmission statistics by importance according to the present disclosure may include at least one of the following information:

[0232] - Reporting Scope: Information regarding the time at which the data included in the report was collected. For example, the start time for reporting data collection and / or the end time for reporting data collection may be provided. If the start time for reporting data collection is not explicitly given, for example, the time at which the associated synchronization source began RTP stream transmission may be considered the start time for reporting data collection. If the end time for reporting data collection is not explicitly given, for example, the time at which the associated RTCP sender report was generated may be considered the end time for reporting data collection. When a PDU Set-based RTCP sender report according to the present disclosure is transmitted in the same UPD payload as a Sender Report RTCP packet identified as PT=200, the time at which the PDU Set-based RTCP sender report was generated may be considered to be the same as the time referred to by the NTP timestamp of said Sender Report RTCP packet.

[0233] - Data transmission amount by importance: Data transmitted by the associated synchronization source within the reporting range may be provided in at least one of the number of packets, number of bytes, or relative ratio by importance. If data corresponding to a specific importance value is not transmitted within the reporting range, it may have a value of 0 or be omitted.

[0234] - Use of PDU set importance values: Whether data is transmitted according to the importance value. For example, it may be expressed using an indicator allocated 1 bit for each importance. For another example, for transmission efficiency, it may be encoded and expressed in conjunction with the amount of data transmitted for each importance. In the PDU Set Marking according to the present disclosure, the importance of the PDU Set may be expressed as an integer from 0 to 15, for example, but this does not mean that media data exists for all importance values. For example, when a data unit output by a media codec has three types of importance, the first media transmission device may express it using importance values ​​1, 2, and 3, whereas the second media transmission device may express it using importance values ​​1, 5, and 10.

[0235] A threshold of importance value essential for media playback according to the present disclosure may be expressed, for example, as a range from 1 to 15. As another example, a real-time communication service according to the present disclosure may define the meaning of the threshold, in which case the threshold of the importance value may include one or more pairs of the meaning of the threshold and the threshold value. For example, when the definition of the threshold is No freeze (no screen freezing at all) or Compotable (some screen freezing may occur), the threshold of the importance value may be provided in the form of (No freeze, 10) and (Compotable, 5).

[0236] The SDP according to the present disclosure may include an attribute that provides information regarding media-specific importance.

[0237] For example, the packet transmission information attributes by importance according to the present disclosure may provide packet transmission statistics estimates by importance according to codecs and media parameters. The media description of the SDP according to the present disclosure may include one or more packet information transmission attributes by importance. The packet transmission information attributes by importance may be expressed, for example, as the Augmented Backus-Naur Form (ABNF) of Table 6 below.

[0238] attribute-name = "importance-map"attribute-value = [scope] importance_amount *("," importance_amount)scope = (payload_type / media_source)";"payload_type = "PT=" PT_value*(","PT_value)PT_value = integer; 0 .. 255media_source = "SSRC=" ssrc_id*(","ssrc_id)ssrc_id = integer; 0 .. 2*32 - 1importance_amount = "("importance","portion")"importance = integer; 0..15portion = integer; 0..255

[0239] In [Table 6] above, the 'importance_amount' parameter may be provided only when the value of the associated 'portion' parameter is greater than 0. In [Table 6] above, the absence of the 'scope' parameter may mean that the subsequent 'importance_amount' parameter is applied to all payload formats (PT) and synchronization sources (SSRC) included in the media description associated with it. In [Table 6] above, the 'portion' parameter may contain information regarding the proportion of packets corresponding to the value of the associated 'importance' parameter. For convenience of explanation, let portion[i] be the value of the 'portion' parameter associated with the 'importance' parameter value i, and let total_portion be portion[0] + portion[1] + … + portion

[0015] . For example, the proportion of transmitted packets corresponding to the importance value i may be given as portion[i] / total_portion. As another example, portion[i] can directly represent the ratio of packets corresponding to importance value i relative to the total number of transmitted packets, in which case the format of the 'portion' parameter in [Table 6] above can be a floating number rather than an integer.

[0240] For example, the importance threshold attribute according to the present disclosure may provide threshold information based on codec and media parameters. The threshold attribute may be expressed as ABNF in Table 7 below, for example.

[0241] attribute-name = "importance-thr" attribute-value = [scope] thr_value / thr_listscope = (payload_type / media_source)";"payload_type = "PT=" PT_value*(","PT_value)PT_value = integer; 0 .. 255media_source = "SSRC=" ssrc_id*(","ssrc_id)ssrc_id = integer; 0 .. 2*32 - 1thr_value = integer; 0 .. 15thr_list = thr_pair *(","thr_pair)thr_pair = "(" semantic","thr_value")" semantic = token

[0242] In the above [Table 7], the absence of the 'scope' parameter may mean that the subsequent 'thr_value' parameter or 'thr_list' parameter applies to all payload formats (PT) and synchronization sources (SSRC) included in the associated media description.

[0243] A media receiving device according to the present disclosure may request a packet retransmission from a media transmitting device using the media-specific importance-related information described above.

[0244] For example, it is assumed that in the SDP negotiation process of a real-time communication service composed of voice and video, the threshold attribute value for voice data is set to 5 and the threshold attribute value for video data is set to 7. A media receiving device according to the present disclosure may, for example, estimate the importance of a lost packet as follows:

[0245] - When a PDU set is divided into multiple packets and transmitted, the PDU SN within a PDU set of the received packets is examined to identify the PDU set in which some packets were not received, and the importance of that PDU set can be regarded as the importance of the lost packets.

[0246] - When a PDU set consists of a single packet or consecutive packets are lost, the importance of the lost packets can be estimated using the relevant media codec setting parameters, packet transmission statistics by importance, and the importance of the received PDU set. For example, assume that media data is transmitted in a repeating pattern of three P frames following an I frame, depending on the video codec settings. If we assume that packets corresponding to the I frame were received before the lost packet and P frames were received after the lost packet, it can be inferred that the lost packet contains media data corresponding to the P frames, and its importance is the same as that of media data containing other P frames.

[0247] A media receiving device according to the present disclosure may determine whether to request retransmission by comparing the estimated importance value with a threshold of the associated media after estimating the importance of a lost packet. For example, if the estimated importance of a lost voice packet is greater than the threshold of 5, a retransmission request may not be made, and if the estimated importance of a lost video packet is greater than the threshold of 7, a retransmission request may not be made.

[0248] A network device according to the present disclosure may determine a packet processing policy to be applied during network congestion by using media-specific importance information. For example, the media-specific importance information may be provided to a PCF (113) directly from an AF (121) or via an NEF (114), and the PCF (113) may aggregate the information received from the AF (121) in units of QoS flows and transmit it directly to a UPF (103) and / or an NG-RAN (102) or via another NF. The UPF (103) and / or an NG-RAN (102) that has acquired the media-specific importance information in units of QoS flows may use the information to determine which packets to process for loss when network congestion occurs. For example, consider a case where the media-specific importance information is as shown in the following [Table 8].

[0249] Importance 13579 Packet Ratio 40% 20% 15% 15% 10%

[0250] In this case, the network according to the present disclosure may select and process packets corresponding to importance level 9 when, for example, 10% of packets need to be processed for loss due to network congestion, and may select and process packets corresponding to importance levels 7 and 9 when 25% of packets need to be processed for loss. In addition, when applying a joint packet processing policy for multiple QoS flows, media-specific importance threshold values ​​may be additionally considered to allocate resources so that threshold conditions are satisfied in the associated QoS flows.

[0251] FIG. 9 is a diagram of user equipment according to one embodiment of the present disclosure.

[0252] In the embodiment of FIG. 9, the user device may be a UE or terminal illustrated in FIG. 1 to FIG. 8, respectively. Referring to FIG. 9, the user device may include a transceiver (910), a control unit (920), and a storage unit (930).

[0253] The transceiver (910) can transmit and receive signals with a base station or network entity. The transceiver (910) can transmit and receive data with a base station or network entity, for example, using wireless communication. In the present disclosure, the transceiver (910) may also be referred to as a transceiver.

[0254] The control unit (920) can control the overall operation of the user device according to the embodiment proposed in the present disclosure. For example, the control unit (920) can control the operation of the user device described with reference to FIGS. 1 through 8. In the present disclosure, the control unit (920) may be defined as a circuit or an application-specific integrated circuit or at least one processor.

[0255] The storage unit (930) can store at least one of the information transmitted and received through the transmission and reception unit (910) and the information generated through the control unit (920). For example, the storage unit (930) can store information and data necessary for the operation method of the user device described with reference to FIGS. 1 to 8.

[0256] FIG. 10 is a diagram of a network entity according to one embodiment of the present disclosure.

[0257] In the embodiment of FIG. 10, the network entity may be implemented as one of the network entities illustrated in FIGS. 1 to 8, respectively. For example, the network entity may be implemented as one of a base station (NG-RAN), a UPF device, an AMF device, an SMF device, a PCF device, an NEF device, an NRF device, an AUSF device, a UDM device, an AF device, an AS device, an Applicability provider, or a proxy server. Referring to FIG. 10, the network entity may include a transceiver (1010), a control unit (1020), and a storage unit (1030).

[0258] The transceiver (1010) can transmit and receive signals with a terminal, a base station, or other network entity. The transceiver (1010) can transmit and receive data with a terminal, a base station, or other network entity, for example, using wireless communication. In the present disclosure, the transceiver (1010) may also be referred to as a transceiver.

[0259] The control unit (1020) can control the overall operation of a network entity according to an embodiment proposed in the present disclosure. For example, the control unit (1020) can control the signal flow between each block to perform the operation of the network entity described with reference to FIGS. 1 through 8. In the present disclosure, the control unit (1020) may be defined as a circuit or an application-specific integrated circuit or at least one processor.

[0260] The storage unit (1030) can store at least one of the information transmitted and received through the transmission and reception unit (1010) and the information generated through the control unit (1020). For example, the storage unit (1030) can store information and data necessary for the operation method of a network entity described with reference to FIGS. 1 to 8.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims

1. A method of a media receiving device for supporting real-time communication services in a wireless communication system, A step of receiving a PDU set (protocol data unit set)-based RTCP (real-time transport control protocol) sender report from a media transmission device, which includes at least one of packet transmission statistics by importance and threshold values ​​of importance required for media playback; A step of processing packet loss using the above PDU set-based RTCP sender report; and A method comprising the step of requesting packet retransmission to the media transmission device based on the processing result of the above packet loss.

2. In paragraph 1, the above packet transmission statistics by importance are, A method comprising at least one of information regarding the time at which data included in the reporting was collected, the amount of data transmitted by importance of the associated synchronization source within the reporting range, or whether PDU set importance values ​​are used.

3. In paragraph 1, the importance value required for the media playback is, A method comprising one or more pairs consisting of a threshold of the importance value required for the above media playback and a definition of the above threshold.

4. In Paragraph 1, A method further comprising the step of identifying a set of PDUs in which some packets are not received when the above set of PDUs is divided into multiple packets and transmitted, and considering the importance of the identified set of PDUs as the importance of the lost packets.

5. In Paragraph 1, A method further comprising the step of estimating the importance of a lost packet based on the media codec setting parameter, an estimate of packet transmission statistics by importance, and the importance of the received PDU set when the above PDU set consists of a single packet or consecutive packets are lost.

6. A method of a media transmission device for supporting real-time communication services in a wireless communication system, A step of generating a PDU set (protocol data unit set)-based RTCP (real-time transport control protocol) sender report including at least one of the packet transmission statistics by importance and threshold values ​​of importance required for media playback; The step of transmitting the above PDU set-based RTCP sender report to a media receiving device; and A method comprising the step of receiving a packet retransmission request from the media receiving device based on a packet loss result processed according to the above PDU set-based RTCP sender report.

7. In paragraph 6, the above packet transmission statistics by importance are, A method comprising at least one of information regarding the time at which data included in the reporting was collected, the amount of data transmitted by importance of the associated synchronization source within the reporting range, or whether PDU set importance values ​​are used.

8. In paragraph 6, the importance value required for the above media playback is, A method comprising one or more pairs consisting of a threshold of the importance value required for the above media playback and a definition of the above threshold.

9. In a media receiving device for supporting real-time communication services in a wireless communication system, Transmitter / receiver; and It includes a control unit, and the control unit is: Receiving a PDU set (protocol data unit set)-based RTCP (real-time transport control protocol) sender report from a media transmission device that includes at least one of packet transmission statistics by importance and threshold values ​​of importance required for media playback, and Packet loss is handled using the above PDU set-based RTCP sender report, and A device that requests packet retransmission to the media transmission device based on the processing result of the above packet loss.

10. In paragraph 9, the above packet transmission statistics by importance are, A device comprising at least one of information regarding the time at which data included in the reporting was collected, the amount of data transmitted by importance of the associated synchronization source within the reporting range, or whether the PDU set importance value is used.

11. In paragraph 9, the importance value required for the above media playback is, A device comprising one or more pairs consisting of a threshold of the importance value required for the above media playback and a definition of the above threshold.

12. In paragraph 9, the control unit is, A device that, when the above PDU set is divided into multiple packets and transmitted, identifies a PDU set in which some packets have not been received, and considers the importance of the identified PDU set as the importance of the lost packets.

13. In paragraph 9, the control unit is, A device for estimating the importance of a lost packet based on the media codec setting parameter, an estimate of packet transmission statistics by importance, and the importance of the received PDU set when the above PDU set consists of a single packet or consecutive packets are lost.

14. In a media transmission device for supporting real-time communication services in a wireless communication system, Transmitter / receiver; and It includes a control unit, and the control unit is: Generates a PDU set (protocol data unit set)-based RTCP (real-time transport control protocol) sender report including at least one of the packet transmission statistics by importance and thresholds of importance values ​​required for media playback, and Transmit the above PDU set-based RTCP sender report to a media receiving device, and A device that receives a packet retransmission request from the media receiving device based on a packet loss result processed according to the above PDU set-based RTCP sender report.

15. In paragraph 14, the above-mentioned packet transmission statistics by importance include at least one of information regarding the time at which data included in the reporting was collected, the amount of data transmitted by importance by the associated synchronization source within the reporting range, or whether the PDU set importance value is used. A device comprising one or more pairs, wherein the importance value required for the media playback is a threshold of the importance value required for the media playback and a definition of the threshold.

Images