Method and device for forward error correction signaling based on packet data unit set in wireless communication system

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting higher data transmission rates. According to the present disclosure, a method of a network entity for forward error correction (FEC) signaling in a wireless communication system comprises the steps of: receiving a stream endpoint configuration parameter including an FEC configuration parameter; generating an FEC repair packet for a data packet on the basis of the FEC configuration parameter; and transmitting the data packet and the generated FEC repair packet to a user plane function (UPF).

Description

Method and device for forward error correction signaling based on packet data unit set in wireless communication system

[0001] The present disclosure relates to a wireless communication system, and more particularly, to a method and device for providing network adaptive media services in a wireless network such as 5G.

[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 the sub-6GHz frequency band such as 3.5 gigahertz (3.5GHz), but also in the ultra-high frequency band called millimeter wave (mmWave) such as 28GHz and 39GHz ('Above 6GHz'). In addition, for 6G mobile communication technology, which is called the system after 5G communication (Beyond 5G), implementation in the terahertz band (for example, the 3 terahertz (3THz) band at 95GHz) is being considered to achieve a transmission speed that is 50 times faster than 5G mobile communication technology and an ultra-low latency time that is reduced to one-tenth.

[0003] In the early stages of 5G mobile communication technology, the goal is to support services and satisfy performance requirements for enhanced Mobile Broadband (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and massive Machine-Type Communications (mMTC). These include beamforming and massive MIMO to mitigate path loss of radio waves in ultra-high frequency bands and increase the transmission distance of radio waves, support for various numerologies (such as operation of multiple subcarrier intervals) and dynamic operation of slot formats for efficient use of ultra-high frequency resources, initial access technology to support multi-beam transmission and wideband, definition and operation of BWP (Bidth Part), new channel coding methods such as LDPC (Low Density Parity Check) codes for large-capacity data transmission and Polar Code for reliable transmission of control information, and L2 pre-processing (L2). Standardization has been made for network slicing, which provides dedicated networks specialized for specific services, and pre-processing.

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

[0005] In addition, standardization of wireless interface architecture / protocols is in progress for technologies such as intelligent factories (Industrial Internet of Things, IIoT) to support new services through linkage and convergence with other industries, Integrated Access and Backhaul (IAB) that provides nodes for expanding network service areas by integrating wireless backhaul links and access links, Mobility Enhancement technology including Conditional Handover and Dual Active Protocol Stack (DAPS) handover, and 2-step random access (2-step RACH for NR) that simplifies random access procedures. Standardization is also in progress for system architecture / services such as 5G baseline architecture (e.g., Service-based Architecture, Service-based Interface) for grafting Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) that provides services based on the location of the terminal.

[0006] Once these 5G mobile communication systems are commercialized, an explosive increase in connected devices will be connected to the communication network, necessitating enhanced functionality and performance of 5G mobile communication systems and integrated operation of these connected devices. To this end, new research will be conducted on improving 5G performance and reducing complexity, supporting AI services, supporting metaverse services, and drone communications by utilizing eXtended Reality (XR), Artificial Intelligence (AI), and Machine Learning (ML) to efficiently support Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR).

[0007] In addition, the development of these 5G mobile communication systems includes new waveforms to ensure coverage in the terahertz band of 6G mobile communication technology, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), Array Antenna, and Large Scale Antenna, metamaterial-based lenses and antennas to improve the coverage of terahertz band signals, high-dimensional spatial multiplexing technology using Orbital Angular Momentum (OAM), Reconfigurable Intelligent Surface (RIS) technology, as well as full duplex technology to improve the frequency efficiency and system network of 6G mobile communication technology, satellite, AI (Artificial Intelligence) from the design stage and AI-based communication technology that realizes system optimization by internalizing end-to-end AI support functions, and ultra-high-performance communication and computing resources to provide services with complexity that exceeds the limits of terminal computing capabilities. It can serve as a basis for the development of next-generation distributed computing technologies that can be realized by utilizing them.

[0008] As described above and with the development of wireless communication systems, various services have become available, and methods for effectively providing these services are required, and in particular, methods for efficiently transmitting real-time media such as voice and video calls are required.

[0009] The present disclosure provides a device and method for PDU set-based forward error correction (FEC) signaling for network adaptive media services in a wireless communication system.

[0010] According to the present disclosure, a method of a network entity for forward error correction (FEC) signaling in a wireless communication system may include the steps of: receiving stream termination configuration parameters including FEC configuration parameters; generating an FEC repair packet for a data packet based on the FEC configuration parameters; and transmitting the data packet and the generated FEC repair packet with a user plane function (UPF).

[0011] According to the present disclosure, a network entity for forward error correction (FEC) signaling in a wireless communication system includes a transceiver; and at least one processor; wherein the at least one processor is configured to receive stream termination configuration parameters including FEC configuration parameters, generate an FEC repair packet for a data packet based on the FEC configuration parameters, and transmit the data packet and the generated FEC repair packet with a user plane function (UPF).

[0012] According to the present disclosure, a method for providing a real-time communication service may include the steps of providing a PDU Set-based QoS-related policy request and PDU Set-based FEC setting information for the real-time communication service to a PCF; creating a media transmission session between entities participating in the real-time communication service based on the QoS-related policy request and PDU Set-based FEC setting information; and transmitting media data through the media transmission session.

[0013] According to the present disclosure, the PDU Set-based QoS related policy and PDU Set-based FEC setting information can be provisioned by a service provider.

[0014] The device and method according to the present disclosure can effectively provide real-time communication services in a mobile communication system.

[0015] The effects that can be obtained from the present disclosure are not limited to the effects mentioned in the various embodiments, and other effects that are not mentioned can be clearly understood by a person having ordinary skill in the art to which the present disclosure belongs from the description below.

[0016] FIG. 1 is a conceptual diagram illustrating a 5G system structure for real-time communication service in a wireless communication system according to the present disclosure.

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

[0018] FIG. 3 is a conceptual diagram illustrating a packet header in a wireless communication system according to the present disclosure.

[0019] FIG. 4 is a diagram illustrating an example of an extension header according to an embodiment of the present disclosure.

[0020] FIG. 5 is a diagram illustrating an example of a single parity check code according to an embodiment of the present disclosure.

[0021] FIG. 6 is a diagram illustrating an example of an RTP extension header for single PDU Set-based FEC according to an embodiment of the present disclosure.

[0022] FIG. 7 is a diagram illustrating an example of an RTP extension header for multiple PDU Set-based FEC according to an embodiment of the present disclosure.

[0023] FIG. 8 is a conceptual diagram illustrating a 5G system configuration information flow for real-time communication service in a wireless communication system according to an embodiment of the present disclosure.

[0024] FIG. 9 is a flowchart illustrating a procedure for establishing a real-time media transmission session in a wireless communication system according to an embodiment of the present disclosure.

[0025] FIG. 10 is a flowchart illustrating a procedure for processing a downlink packet for a real-time communication service in a wireless communication system according to an embodiment of the present disclosure.

[0026] FIG. 11 is a flowchart illustrating the operation of a network entity according to an embodiment of the present disclosure.

[0027] FIG. 12 is a structural diagram illustrating the structure of a network entity according to an embodiment of the present disclosure.

[0028] The operating principles of the present invention will be described in detail below with reference to the attached drawings. In the following description of the present invention, detailed descriptions of known functions or components will be omitted if they are deemed to unnecessarily obscure the gist of the invention. Furthermore, the terms described below are defined based on their functions in the present invention and may vary depending on the intentions or practices of the user or operator. Therefore, their definitions should be based on the overall content of this specification.

[0029] For the same reason, some components in the attached drawings are exaggerated, omitted, or schematically depicted. Furthermore, the dimensions of each component do not entirely reflect its actual size. Identical or corresponding components in each drawing are assigned the same reference numbers.

[0030] The advantages and features of the present invention, and the methods for achieving them, will become clearer with reference to the embodiments described in detail below together with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below and may be implemented in various different forms. These embodiments are provided only to ensure that the disclosure of the present invention is complete and to fully inform those skilled in the art of the scope of the invention, and the present invention is defined only by the scope of the claims. Like reference numerals designate like elements throughout the specification.

[0031] At this time, it will be understood that each block of the processing flowchart drawings and combinations of the flowchart drawings can be performed by computer program instructions. These computer program instructions can be installed in a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, so that the instructions executed by the processor of the computer or other programmable data processing equipment create a means for performing the functions described in the flowchart block(s). These computer program instructions can also be stored in a computer-available or computer-readable memory that can direct a computer or other programmable data processing equipment to implement the functions in a specific manner, so that the instructions stored in the computer-available or computer-readable memory can also produce a manufactured item that includes an instruction means for performing the functions described in the flowchart block(s). Since the computer program instructions may be installed on a computer or other programmable data processing device, a series of operational steps may be performed on the computer or other programmable data processing device to create a computer-executable process, and the instructions that cause the computer or other programmable data processing device to perform the steps for performing the functions described in the flowchart block(s) may also provide steps for performing the functions described in the flowchart block(s).

[0032] Additionally, each block may represent a module, segment, or portion of code that contains one or more executable instructions for performing a specific logical function(s). It should also be noted that in some alternative implementation examples, the functions described in the blocks may occur out of order. For example, two blocks depicted in succession may actually be executed substantially concurrently, or the blocks may sometimes be executed in reverse order, depending on their respective functions.

[0033] Here, the term '~ part' used in the present embodiment means software or hardware components such as FPGA (Field Programmable Gate Array) or ASIC (Application Specific Integrated Circuit), and the '~ part' performs certain roles. However, the '~ part' is not limited to software or hardware. The '~ part' may be configured to be on an addressable storage medium and may be configured to play one or more processors. Therefore, as an example, the '~ part' includes components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, 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'. Additionally, the components and '~parts' may be implemented to activate one or more CPUs within a device or secure multimedia card. In addition, in an embodiment, the '~parts' may include one or more processors.

[0034] In the following description of the present disclosure, detailed descriptions of related known functions or configurations will be omitted if they are deemed to unnecessarily obscure the gist of the present disclosure. Hereinafter, embodiments of the present disclosure will be described with reference to the attached drawings.

[0035] In this disclosure, phrases such as "A / B", "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" can each include any one of the items listed together in that phrase, or all possible combinations thereof. Terms such as "first", "second", or "first" or "second" may be used merely to distinguish the corresponding component from other corresponding components and do not limit the corresponding components in any other respect (e.g., importance or order).

[0036] The terms used in the following description to identify connection nodes, terms referring to network entities (NFs), terms referring to messages, terms referring to interfaces between NFs, terms referring to various identification information, etc. are provided as examples for convenience of explanation. Therefore, the present disclosure is not limited to the terms described below, and other terms referring to objects having equivalent technical meanings may be used.

[0037] The terms used in this disclosure are used only to describe specific embodiments and may not be intended to limit the scope of other embodiments. The singular expression may include plural expressions unless the context clearly indicates otherwise. Terms used herein, including technical or scientific terms, may have the same meaning as commonly understood by those of ordinary skill in the art described in this disclosure. Terms defined in general dictionaries among the terms used in this disclosure may be interpreted as having the same or similar meaning in the context of the relevant technology, and shall not be interpreted in an idealized or overly formal sense unless explicitly defined in this disclosure. In some cases, even if a term is defined in this disclosure, it cannot be interpreted to exclude embodiments of the present disclosure.

[0038] The various embodiments of the present disclosure described below illustrate a hardware-based approach as an example. However, since the various embodiments of the present disclosure include techniques utilizing both hardware and software, the various embodiments of the present disclosure do not exclude a software-based approach.

[0039] For convenience, the present invention uses terms and names defined in the LTE and NR standards, which are the most recent standards defined by the 3rd Generation Partnership Project (3GPP) among the existing communication standards. However, the present invention is not limited to the above terms and names, and can be equally applied to systems conforming to other standards. In particular, the present invention can be applied to 3GPP NR (5th generation mobile communication standard). Furthermore, the embodiments of the present disclosure can be applied to other communication systems with similar technical backgrounds or channel types. Furthermore, the embodiments of the present disclosure can be applied to other communication systems with some modifications as determined by a person having skilled technical knowledge without significantly departing from the scope of the present disclosure.

[0040] The present disclosure relates to a mobile communication system. If packets constituting a media stream in a mobile communication system supporting real-time communication services are processed according to the same policy, that is, if the differences in the impact of media data contained in each packet on service quality are not considered, it becomes impossible to provide service quality optimized for given network resources. In this case, a technique for improving media quality and saving network resources by utilizing the differences in the impact of media data contained in each packet on service quality in a wireless communication system is described.

[0041] The terms used in the following description, including terms referring to signals, channels, control information, network entities, and device components, are provided for convenience of explanation. Therefore, the present disclosure is not limited to the terms described below, and other terms with equivalent technical meanings may be used.

[0042] Additionally, while this disclosure describes various embodiments using terminology used in certain communication standards (e.g., 3rd Generation Partnership Project (3GPP)), these are merely illustrative examples. The various embodiments of this disclosure can be easily modified and applied to other communication systems.

[0043] Hereinafter, with regard to real-time communication services, a user can use an application provided by a real-time communication application provider to negotiate service setting information including media information with a real-time media server or other users, and based on this, establish a real-time communication media session to mutually exchange media data such as voice and video in real time.

[0044] To provide real-time communication services, 5GS (5G system) may include a new generation-radio access network (NG-RAN) and a user plane function (UPF) in the communication path of the real-time communication media session.

[0045] Real-time communication services can be composed of media with various transmission characteristics, such as voice, video, and text, and can include repair data for forward error correction (FEC). To guarantee the QoS of real-time communication services, the network can consider information for identifying packets containing the media data or repair data, as well as transmission characteristics for each medium. A typical communication system defines a packet flow, which is a set of packets to which the same QoS is provided, and sets the operations of network entities located along the communication path of the media session.

[0046] Information for configuring the operation of the above network entity may include information for identifying packets belonging to the packet flow and a QoS policy to be applied to packets belonging to the packet flow. Information for identifying the packet flow includes transmitting and receiving IP addresses, transmitting and receiving port numbers (e.g., TCP or UDP port numbers), transmission protocol identifiers, etc. For example, in a real-time communication service including voice and video, if uninterrupted transmission of voice information is important, the voice information may be transmitted in a separate packet flow that provides a higher QoS.

[0047] Data units that constitute media may have different importance and interrelationships depending on the characteristics of the media. For example, in video compression, an intra-frame may affect the restoration of other frames that reference it. 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. However, data units that constitute media data may not be preserved during the packetization process for network transmission but may be fragmented into multiple packets, and if even some of the fragmented packets are damaged or lost depending on the characteristics of the media codec, restoration of the media unit at the receiving end may be impossible. To solve this problem, the present disclosure provides a signaling method that generates FEC repair data for each media data unit and associates a media packet flow protected by the FEC repair data with a packet flow that includes the FEC repair data.

[0048] The devices and methods according to various embodiments of the present disclosure described below enable real-time communication service providers to provide QoS considering media characteristics when providing real-time services in 5GS (5G system).

[0049] The effects that can be obtained from the present disclosure are not limited to the effects mentioned above, and other effects that are not mentioned can be clearly understood by a person having ordinary skill in the art to which the present disclosure belongs from the description below.

[0050] Additionally, for convenience, the following description uses terms and names defined in the 5G system standards. However, the present disclosure is not limited to these terms and names, and can be equally applied to systems conforming to other standards.

[0051] FIG. 1 is a conceptual diagram illustrating a 5G system structure (5G system, 5GS) for real-time communication service in a wireless communication system according to the present disclosure.

[0052] Referring to FIG. 1, 5GS may include a user equipment (UE) (101), an 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), a real-time communication application function (RTC AF) device (121), and a real-time communication application server (RTC AS) device (122). Of course, 5GS is not limited to the above examples and may include fewer or more configurations than those illustrated in FIG. 1. Additionally, each device may be referred to as a network entity, a network function, or a network function apparatus.

[0053] Referring to Figure 1, each network function (NF) of 5GS will be described as a "network entity" or "network function" itself. However, those skilled in the art will understand that an NF and / or an NF device may be implemented in one or more specific servers, or two or more NFs performing the same operation may be implemented in a single server.

[0054] Furthermore, according to the present disclosure, one NF or two or more NFs may be implemented in the form of a network slice, depending on the situation. 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, such as a maximum transmission rate and data usage, or a guaranteed minimum transmission rate, to a specific group of subscribers. In addition, a network slice may be implemented for various other purposes. Since network slices are well known to those skilled in the art, a description thereof will be omitted.

[0055] Referring to Fig. 1, Fig. 1 illustrates interfaces between each node. A Uu interface may be used between a UE (101) and an NG-RAN (102), an N2 interface may be used between an NG-RAN (102) and an AMF (111), an N3 interface may be used between an NG-RAN (102) and an UPF (103), an N4 interface may be used between an SMF (112) and an UPF (103), and an N6 interface may be used between the UPF (103) and a 5G RTC AF (121), 5G RTC WSF, and 5G RTC AS (122) located in a DN (data network). Since the above-described interfaces are defined in the 3GPP standard, their descriptions are omitted. The interfaces between the RTC AF (121) and the RTC AS (122) and the UE will be described in the media architecture described later.

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

[0057] As described above, the data units constituting the media data may be divided into multiple packets rather than being preserved during the packetization process for network transmission. For example, general video data may be composed of a group of pictures (GOP) including pictures such as an I picture (intra-coded picture), a P picture (predictive-coded picture), and a B picture (bidirectional-coded picture), and the picture set may include at least one I picture.

[0058] Referring to FIG. 2, one image set may be composed 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, i.e., PL1 (211), PL2 (212), PL3 (213), and PL4 (214), and transmitted as four packets (261, 262, 263, 264) each including a payload. The four packets (261, 262, 263, 264) may include headers (HD1 (251), HD2 (252), HD3 (253), HD4 (254)) corresponding to each payload (PL1 (211), PL2 (212), PL3 (213), PL4 (214)). Hereafter, a set of payloads divided from a single media data unit can be referred to as a PDU Set. Referring to FIG. 2, four payloads, PL1 (211), PL2 (212), PL3 (213), and PL4 (214), constituting the I frame (210), can constitute one PDU Set, and two payloads, PL1 (241) and PL (242), constituting the P frame (240) can constitute another PDU Set.

[0059] The above packet is composed of a header and a payload, and the header may include information necessary for the network to process the packet and transmit it to the destination, and the payload may include information necessary for the receiver to process media data and may include a separate payload header according to the media data processing method. The network may utilize data included in the packet header and payload to identify the packet.

[0060] When a network identifies packets containing PDUs belonging to the same PDU Set, packet processing can be performed based on the PDU Set. For example, when a communication volume exceeds the processing capacity of a network, packet loss may occur. In this case, by minimizing the number of lost PDU Sets relative to the number of lost packets through PDU Set-based packet processing, the degradation of service quality can be minimized. Network devices that support the PDU Set-based packet processing may be required to have a function of identifying packets belonging to the same PDU Set and a function of identifying a processing method to be applied to packets belonging to the PDU Set.

[0061] FIG. 3 is a conceptual diagram illustrating an example of a packet header in a wireless communication system according to the present disclosure. Referring to FIG. 3, a real-time transport protocol (RTP) header (320), a user datagram protocol (UDP) header (330), and an internet protocol (IP) header (340) may be added to transmit a packet data unit (PDU) (310). The RTP header (320) may include an RTP extension header.

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

[0063] - version (V): A 2-bit field indicating the RTP version. RTP following IETF RFC 3550 has a value of 2.

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

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

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

[0067] - 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 and transmitted, only the M field value of the last RTP packet among the RTP packets may be set to 1.

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

[0069] - sequence number (SN): A 16-bit field that increases by 1 each time an RTP packet is transmitted. It can be used by the receiver to detect loss and restore packet order.

[0070] - timestamp: A 32-bit field that can indicate the acquisition time or playback time of the data sample included in the RTP packet.

[0071] - SSRC: A 32-bit field indicating the identifier of the synchronization source.

[0072] - CSRC: A 32-bit field indicating the identifier of the contribution source.

[0073] A real-time media service according to an embodiment of the present disclosure may include one or more media transport sessions, and information about the media transport sessions may be configured as a 5-tuple (source IP address, destination IP address, source port number, destination port number, transport protocol). Therefore, packets that use the RTP / UDP / IP protocol, such as the packets shown in FIG. 3, and in which the source / destination IP address values ​​of the IP header (340) and the source / destination port number values ​​of the UDP header (330) are the same, may be regarded as packets belonging to one media transport session. One media transport session may include one or more RTP streams. Here, an RTP stream is an RTP packet flow having the same SSRC field value, and each packet may include media data or data for loss restoration such as redundant data or FEC repair data.

[0074] A network device can obtain information for identifying a PDU Set including the packet from at least one of a packet header or PDU of the packet and information for determining a processing method to be applied to packets constituting the PDU Set. A media transmission session according to an embodiment of the present disclosure can transmit the information using a packet header and a payload header. The specific formats of the header and payload used to transmit the information and the information included in the header and payload may vary depending on the type of protocol used in the media transmission session and the profile operating the protocol. Hereinafter, a method used to transmit PDU Set related information in the media transmission session may be referred to as a PDU Set Marking method. The PDU Set Marking method according to an embodiment of the present disclosure may include an RTP extension header. In addition, the PDU Set Marking method may be included in network configuration information that supports PDU Set-based packet processing.

[0075] FIG. 4 is a diagram illustrating an example of an extension header according to an embodiment of the present disclosure.

[0076] An RTP extension header can be specified by a Uniform Resource Identifier (URI). For example, the URI for the PDU Set Marking extension header of the RTP extension header of FIG. 4 may be "urn:3gpp:pdu-set-marking:rel-18." Referring to FIG. 4, the format and usage of each field of the extension header are as follows:

[0077] - ID (4 bits): Local identifier of RTP extension header

[0078] - len (4 bits): The length in bytes of the RTP extension header following this field minus 1. For example, a len field value of 0 indicates that there is 1 byte of data following it.

[0079] - End PDU of the PDU Set[E] (1 bit): A flag that has a value of 1 only when it is the last PDU in the PDU Set and a value of 0 otherwise.

[0080] - End of Data Burst [EDB] (3 bits): A 3-bit field indicating the end of a data burst.

[0081] - PDU Set Importance [PSI] (4 bits): A field indicating the relative importance of the associated PDU Set. A smaller value indicates higher importance.

[0082] - PDU Set Sequence Number [PSSN] (10 bits): Indicates the sequence number of the associated PDU Set.

[0083] - PDU Sequence Number within a PDU Set [PSN] (6 bits): Indicates the sequence number of the associated PDU in the PDU Set.

[0084] - PDU Set Size [PSSize] (24 bits): Indicates the length in bytes of the associated PDU Set. This field may be optional, and its presence can be determined during the SDP negotiation process.

[0085] The value of the above ID field and the presence of the PSSize field can be determined during the SDP negotiation process. For example, the m-line (media description) of the negotiated SDP may include the following extmap attribute.

[0086] a = extmap: 1 "urn:3gpp:pdu-set-marking:rel-18" pdu-set-size

[0087] This means that the RTP stream included in the m-line including the extmap attribute may include an RTP extension header identified as "urn:3gpp:pdu-set-marking:rel-18", and at this time, the ID field value of the RTP extension header may be set to "1" and may indicate the presence of a PSSize field.

[0088] FIG. 5 is a diagram illustrating an example of a single parity check code according to an embodiment of the present disclosure.

[0089] A real-time communication service according to an embodiment of the present disclosure may use a Forward Error Correction (FEC) technique to restore lost media data. An example of the FEC technique may be a single parity-check code. An FEC source packet is a packet to be protected using FEC, and may be, for example, an RTP packet containing media data. An FEC repair packet is a packet containing repair data required to restore a lost FEC source packet, and may be, for example, an RTP packet containing repair data and an FEC header. The repair data is generated by an algorithm referred to as an FEC code, and the FEC code may be, for example, a single parity-check code. For convenience of explanation, a single parity-check code that generates one FEC repair packet using K FEC source packets is considered. In this case, a set of FEC source packets to which FEC is applied is called an FEC source packet block.

[0090] Referring to FIG. 5, an FEC source packet block is composed of three FEC source packets (511, 512, 513), and the FEC source packets may be RTP packets in which the SN field values ​​of the RTP header have values ​​of i, i+1, and i+2, respectively. The RTP packets may be converted into protected bit streams (521, 522, 523) before applying FEC. In a single parity check code, a repair bit stream (531) may be calculated as an exclusive OR (XOR) of the protected bit streams. In the XOR operation process, a padding technique that adds a value of 0 may be used when the lengths of the protected bit streams are different, and as a result, the length of the repair bit stream (531) may be equal to the maximum length of the protected bit streams (521, 522, 523). The above repair bit string (531) can be converted into an FEC repair packet (540) and transmitted to the same destination as the FEC source packet.

[0091] The protected bit stream (531) may include all or part of the associated RTP source packet, and additional data may be added for FEC decoding. For example, the protected bit stream (531) may further include the length of the FEC source packet. The FEC repair packet (540) includes an RTP header (541), an FEC header (543), a repair payload (544), and optionally may further include an RTP extension header (542). The repair payload (544) may include all or part of the repair bit stream (531).

[0092] The FEC header (543) may include information for identifying FEC source packets protected by the repair bit string (531). In the embodiment of FIG. 5, the FEC source packet block is three RTP packets (511, 512, 513) whose SN field values ​​of the RTP packet header are i, i+1, and i+2, respectively. The FEC source packet block may be expressed by, for example, i, which is the minimum value of the SN field, and 3, which is the number of FEC source packets belonging to the FEC source packet block. As another example, the FEC source packet block may be expressed by a combination of a base SN field value and a bit mask having a constant length. The bit mask may have a pattern in which the i-th bit value is set to 1 when an FEC source packet having an SN field value of Base_SN + i belongs to the FEC source packet based on the base SN field value (Base_SN). When using an 8-bit bit mask, the FEC source packet block of FIG. 5 can be expressed as SN_Base = i, Mask = 1110 0000 or SN_base = i-2, Mask = 0011 1000.

[0093] Below, a PDU Set-based FEC signaling method according to an embodiment of the present disclosure is described.

[0094] The FEC method according to an embodiment of the present disclosure can configure an FEC source packet block in units of PDU Sets. For example, the FEC source packet block for each FEC repair packet can be configured with all or part of the FEC source packets included in one or more PDU Sets transmitted in a single RTP stream. As another example, the FEC source packet block for each FEC repair packet can be configured with all or part of the FEC source packets belonging to one or more PDU Sets transmitted in two or more RTP streams. In this case, the mapping relationship between the FEC source packet block and the PDU Set can be signaled in at least one of an out-of-band (from the perspective of the RTP stream) signaling such as SDP and an RTP extension header. In addition, the identifier of the PDU Set associated with the FEC source packet block can be signaled in the RTP extension header of the FEC repair packet.

[0095] FIG. 6 is a diagram illustrating an example of an RTP extension header for single PDU Set-based FEC according to an embodiment of the present disclosure.

[0096] For example, if the URI (Uniform Resource Identifier) ​​of the RTP extension header of FIG. 6 is "urn:1pdu-set-FEC", then the use of the RTP extension header having the "urn:1pdu-set-FEC" as a URI can be expressed as the extmap attribute of SDP as follows:

[0097] a = extmap: 1 "urn:1pdu-set-FEC" PSN

[0098] This means that the FEC repair packet of the RTP stream included in the m-line including the extmap attribute may include an RTP extension header identified as "urn:1pdu-set-FEC", wherein the ID field value of the RTP extension header is set to "1" and may indicate the presence of a PSN (PDU sequence number within a PDU set) field. Furthermore, using the RTP extension header identified as "urn:1pdu-set-FEC" means that the FEC source packet block is always included in a single PDU Set, which may be agreed upon between real-time communication service participants using the SDP negotiation process.

[0099] Referring to Figure 6, the format and usage of at least one field that may be included in an RTP extension header identified as "urn:1pdu-set-FEC" are as follows:

[0100] - ID (4 bits): Local identifier of the RTP extension header. If its use is signaled by the a=extmap attribute of the above SDP, the ID field has 1.

[0101] - len (4 bits): This field has a value of 1, which is the length in bytes of the RTP extension header following this field minus 1.

[0102] - PDU Set Sequence Number [PSSN] (10 bits): Indicates the sequence number of the PDU Set containing the FEC source packet block of the associated FEC repair packet.

[0103] - PDU Sequence Number within a PDU Set [PSN] (6 bits): Indicates the sequence number of the PDU corresponding to the first FEC source packet in the FEC source packet block of the associated FEC repair packet. (For example, the PDU sequence number of an RTP packet with an SN field value corresponding to SN_base)

[0104] Depending on the implementation, the above PSN field value may be optionally provided (if not provided, it always has a value of 000000), and in this case, the presence or absence of the PSN field may be negotiated through the a=extmap attribute described above.

[0105] FIG. 7 is a diagram illustrating an example of an RTP extension header for multiple PDU Set-based FEC according to an embodiment of the present disclosure.

[0106] For example, let's say the URI of the RTP extension header in Fig. 7 is "urn:Npdu-set-FEC". In this case, the use of the RTP extension header having the "urn:Npdu-set-FEC" as a URI can be expressed as the extmap attribute of SDP as follows:

[0107] a = extmap: 2 "urn:Npdu-set-FEC" PSN

[0108] This means that the FEC repair packet of the RTP stream included in the m-line including the extmap attribute may include an RTP extension header identified as "urn:Npdu-set-FEC", wherein the ID field value of the RTP extension header may be set to "2" and may indicate the presence of a PSN field. In addition, the use of the RTP extension header identified as "urn:Npdu-set-FEC" means that an FEC source packet block may be composed of FEC source packets included in one or more PDU Sets, which may be agreed upon between real-time communication service participants using an SDP negotiation process.

[0109] Referring to Figure 7, the format and usage of at least one field that may be included in an RTP extension header identified as "urn:Npdu-set-FEC" are as follows:

[0110] - ID (4 bits): Local identifier of the RTP extension header. If its use is signaled by the a=extmap attribute of the above SDP, the ID field has 1.

[0111] - len (4 bits): The length in bytes of the RTP extension header following this field minus 1.

[0112] - # of PDU Sets[NPDUS]: The number of PDU Sets that contain one or more FEC source packets in the FEC source packet block of the associated FEC repair packet. Indicates the number of PSSN / PSN field pairs to follow.

[0113] - PDU Set Sequence Number [PSSN] (10 bits): Indicates the sequence number of the PDU Set containing the FEC source packet block of the associated FEC repair packet.

[0114] - PDU Sequence Number within a PDU Set [PSN] (6 bits): Indicates the sequence number of the PDU corresponding to the first FEC source packet in the FEC source packet block of the associated FEC repair packet. (For example, the PDU sequence number of an RTP packet with an SN field value corresponding to SN_base)

[0115] The above NPDUS field and the number of PSSN / PSN field pairs following it as NPDUS field values ​​constitute an FEC Source Packet Block (SPB) signaling block for one RTP stream. When an FEC SPB (Source Packet Block) is composed of all or part of FEC source packets belonging to one or more PDU Sets transmitted in two or more RTP streams, the RTP extension header identified as "urn:Npdu-set-FEC" may include one or more FEC SPB signaling blocks. The RTP extension header illustrated in FIG. 7 assumes that the number of RTP streams and the SSRC value are signaled in a separate manner. For example, the SSRC values ​​of the protected RTP streams may be signaled by the CSRC field present in the RTP header of the FEC repair packet. If such a separate signaling method is not used, or for interoperability with a PDU Set-based transmission system such as 5G described later, the RTP extension header illustrated in FIG. 7 may further include the number of protected RTP streams and SSRC values. In addition, the PSN field value may be optionally provided, and in this case, the presence or absence of the PSN field may be negotiated through the a=extmap attribute described above. Depending on the implementation, non-provision of the PSN field value may mean that the bits at the corresponding position are set to 0, or that the PSN field does not exist.

[0116] FIG. 8 is a conceptual diagram illustrating a 5G system configuration information flow for real-time communication services in a wireless communication system according to various embodiments of the present disclosure.

[0117] Referring to FIG. 8, the RTC AF (820) may request the 5G CN (830) to establish a real-time media transmission session including QoS setting parameters based on the service setting information provided by the service provider (810). The QoS setting parameters may include information on the PDU Set Marking method and PDU Set-based FEC setting information. If the session establishment request is successful, the RTC AF (820) may set the RTC AS (840) to perform the role of a stream termination server, and the 5G CN (830) may set the UPF (850) and RAN (860) located in the path of the real-time communication media session.

[0118] When a service is initiated, the RTC AS (840) may transmit one or more media streams to which PDU Set Marking is applied to the UPF (850). The PDU Set Marking of the media stream may include a media analysis process, a PDU Set related information setting process, and a packetization process. When FEC is applied to the media stream, the RTC AS (840) or a separate device located in the network may transmit an FEC repair stream that protects the media stream to the UPF (850), and the FEC repair packet included in the FEC repair stream may include protected PDU Set identification information. In addition, PDU Set Marking may be selectively applied to the FEC repair stream. The PDU Set Marking of the FEC repair stream may include a PDU Set Marking analysis process applied to the FEC repair stream, a PDU Set related information setting process, and a packetization process.

[0119] The UPF (850) that receives the media stream can identify packets included in the real-time communication media session using a packet filter, and can identify a PDU Set and process packets using PDU Set Marking method information included in the configuration information of the 5G CN (830). Thereafter, the UPF (850) transmits a media packet with a GTP (GPRS (General Packet Radio Service) Tunneling Protocol) header added to the RAN (860), and when the RAN (860) provides PDU Set-based packet processing, PDU Set-related information can be added to the GTP header. Similarly, the UPF (850) that receives the FEC repair stream can identify FEC repair packets using a packet filter, and can identify FEC repair packets associated with a specific PDU Set using PDU Set Marking method information and PDU Set-based FEC configuration information included in the configuration information of the 5G CN (830), and process the same.

[0120] Thereafter, the UPF (850) transmits the FEC repair packet with the GTP header added to the RAN (860). If the RAN (860) provides PDU Set-based packet processing, PDU Set related information can be added to the GTP header, and if the RAN (860) supports PDU Set-based FEC repair packet processing, protected PDU Set identification information can be added to the GTP header. The protected PDU Set identification information can include, for example, an RTP extension header having the above-described "urn:1pdu-set-FEC" or "urn:Npdu-set-FEC" as a URI.

[0121] In addition, the PDU Set-based FEC repair packet processing of the UPF (850) and RAN (860) may require FEC detailed parameters. For example, at least one of the UPF (850) or the RAN (860) may filter and transmit only the related FEC repair packets when packet loss occurs. In this case, detailed information about the FEC source packet associated with the FEC repair packet is required to find the FEC repair packet associated with the lost packet. In this case, the UPF (850) may add the FEC header (543) of the packet FEC repair packet (540) illustrated in FIG. 5 to the GTP header. In another embodiment of the present invention, the FEC header (543) may be added to the above-described RTP extension headers or configured as a separate extension header and included in the FEC repair packet by the RTC AS (840).

[0122] The UE (870) may be identical or similar to the UE (101) of FIG. 1. The RAN (860) may be identical or similar to the NG-RAN (102) of FIG. 1. The UPF (850) may be identical or similar to the UPF (103) of FIG. 1. The RTC AS (840) may be identical or similar to the RTC AS (122) of FIG. 1. The RTC AF (820) may be identical or similar to the RTC AF (121) of FIG. 1.

[0123] FIG. 9 is a flowchart illustrating a procedure for establishing a real-time media transmission session in a wireless communication system according to the present disclosure.

[0124] Referring to FIG. 9, process 901 is a process in which the RTC AF (820) sets up a media-based QoS service, and may use service provisioning parameters provided by the RTC service provider (810). For example, the RTC service provider (810) may transmit service provisioning parameters to the RTC AF (820). The RTC AF (820) may receive service provisioning parameters from the RTC service provider (810). The service provisioning parameters may include at least one of a codec / protocol configuration, a PDU Set marking / detection scheme, QoS and packet handling parameters, and a PDU Set-based FEC configuration. The PDU Set marking / detection scheme may include at least one of a protocol and extended header information. The above Qos and packet processing parameters may include at least one of EtoE delay, bandwidth, and QoE metric. The PDU Set-based FEC configuration may include at least one of RTP payload type information for FEC, repair stream configuration information, and extended header information to be applied to the FEC repair packet.

[0125] Process 902 may include a process necessary for selecting a PCF (113) to communicate with the RTC AF (820) in a general session establishment procedure (PDU Session Establishment procedure). This may include a PDU session establishment request (UE request) of the UE (870), an SMF selection (SMF selection), an SMContext creation (SMContext creation), a PCF selection (PCF selection) process, etc. For example, the UE (870), the RAN (860), the UPF (850), the SMF (112), and the PCF (113) may perform the session establishment procedure.

[0126] Step 903 is a process in which the RTC AF (820) requests the PCF (113) to allocate resources for a media transmission session, and media session QoS parameters (Parameters for AF Session with Qos) may be provided to the PCF (113). In another embodiment of the present disclosure, the media session QoS parameters may be provided to 5GS before establishing a media session. For example, the RTC AF (820) may transmit the media session QoS parameters to the PCF (113). The PCF (113) may receive the media session QoS parameters from the RTC AF (820). The media session QoS parameters may include at least one of session identification (sending / receiving IP address, sending / receiving port number, protocol), media identification (MIME-type), PDU Set marking / detection scheme, QoS and packet handling parameters, and FEC configuration parameters. The QoS and packet handling parameters may include at least one of PSDB, PSER, loss tolerance, max PDU set size, PDU Set period, and delay / jitter sensitivity. The FEC configuration parameters may include at least one of RTP payload type information for FEC, repair stream identification information, and extended header information to be applied to the FEC repair packet.The extension header information to be applied to the above FEC repair packet may include at least one of a Uniform Resource Name (URN) indicating a PDU Set-based FEC extension header and a local identifier for identifying the PDU Set-based FEC extension header in an RTP packet.

[0127] Process 904 is a process in which the RTC AF (820) sets a stream endpoint (900), and the RTC AF (820) can provide stream endpoint configuration parameters (parameters for SEP (stream endpoint) configuration) to the stream endpoint (900). The RTC AF (820) can transmit the stream endpoint configuration parameters to the stream endpoint (900). The stream endpoint (900) can receive the stream endpoint configuration parameters from the RTC AF (820). The stream endpoint configuration parameters can include at least one of codec / protocol settings, marking / detection methods, QoS and packet processing parameters, and FEC settings. The stream endpoint configuration process can vary depending on the location and characteristics of the stream endpoint (900), and will be described in detail later. For example, the stream end (900) may be an RTC AS (840), an IMS AGW (IMS access gateway), a MRF (media resource function), or a terminal.

[0128] Step 905 is a process in which the PCF (113) generates a PCC (policy and charging control) rule and transmits it to the SMF (112). The PCC rule may include QoS parameters related to a PDU Set. The PCF (113) may transmit the PCC rule to the SMF (112). The SMF (112) may receive the PCC rule from the PCF (113). The PCF (113) and the SMF (112) may perform operations for SM policy association establishment / modification.

[0129] Process 906 is a process in which the SMF (112) configures the RAN (860) and the UPF (850). The SMF (112) uses the PCC rule obtained from the PCF (112) to create a QoS profile and an N4 rule, distributes the N4 rule to the UPF (850), and distributes the QoS profile to the RAN (460) through the AMF (111).

[0130] Step 907 refers to the steps after step 906 (other steps in PDU session establishment or modification) in the general session establishment process, and may include a process of responding to a PDU session establishment request from a UE (870) and setting up access network resources. The SEP (900) of the UE (870) can be configured in step 907 via a NAS SM message or an RRC message (SEP in UE can be configured in step 7 via a NAS SM message or an RRC message).

[0131] In an IMS (IP-multimedia subsystem) network according to an embodiment of the present disclosure, the operation of the RTC AF (820) can be performed in a CSCF (Call Session Control Function) and an IMS AS (application server).

[0132] The service provisioning parameters of the above process 901 may include the following information.

[0133] - Types and settings of media codecs available for service: AVC-HD, AVC-FullHD, AVC-UHD, HEVC-HD, HEVC-FullHD, HEVC-UHD, EVS, eAAC+, etc.

[0134] - Media transfer protocols: RTP / UDP / IP, SRTP / DTLS / UDP / IP, HTTP1.x / TCP / IP, HTTP3 / QUIC / UDP, RTP / QUIC / UDP, etc.

[0135] - PDU Set Marking method: RTP payload format media type, RTP header extension URI, etc.

[0136] - QoS-related parameters: PSDB (PDU set delay budget), PSER (PDU set error rate), loss tolerance, PDU set maximum size, PDU set period, end-to-end delay time (EtoE delay), bandwidth, delay / jitter sensitivity, etc.

[0137] - FEC settings: RTP payload format media type of FEC repair packet, RTP header extension URI, FEC repair stream configuration method, etc.

[0138] The media session QoS parameters of the above process 903 may include the following information:

[0139] - Media session identification information: sending and receiving IP addresses, port numbers, protocol identifiers, etc.

[0140] - Media identification information: RTP payload format media type

[0141] - PDU Set Marking method: RTP payload format media type, RTP header extension URI, header extension local identifier mapped to the RTP header extension URI at the multimedia session level or RTP session / stream level, etc.

[0142] - QoS related parameters: PSDB (PDU set delay budget), PSER (PDU set error rate), loss tolerance, PDU set maximum size, PDU set period, bandwidth, delay / jitter sensitivity, etc.

[0143] - FEC settings: RTP payload format media type of FEC repair packet, RTP header extension URI, FEC repair stream identifier (e.g., sending / receiving IP address / port number, RTP Stream Identifier, Media identification (MID), SSRC identifier, etc.)

[0144] The stream termination setting parameters of the above process 904 may include the following information.

[0145] - Types and settings of media codecs available for service: AVC-HD, AVC-FullHD, AVC-UHD, HEVC-HD, HEVC-FullHD, HEVC-UHD, EVS, eAAC+, etc.

[0146] - Media transfer protocols: RTP / UDP / IP, SRTP / DTLS / UDP / IP, HTTP1.x / TCP / IP, HTTP3 / QUIC / UDP, RTP / QUIC / UDP, etc.

[0147] - PDU Set Marking method: RTP payload format media type, RTP header extension URI, etc.

[0148] - QoS-related parameters: PSDB (PDU set delay budget), PSER (PDU set error rate), loss tolerance, PDU set maximum size, PDU set period, end-to-end delay time (EtoE delay), bandwidth, delay / jitter sensitivity, etc.

[0149] - FEC settings: RTP payload format media type of FEC repair packet, RTP header extension URI, FEC repair stream configuration method, etc.

[0150] As described above, the stream termination performing PDU Set Marking may be a stream termination server located on the network or a stream termination terminal owned by the user. The stream termination server may have different configuration procedures depending on the hosting environment or underlying network.

[0151] For example, in the case of an IMS (IP multimedia subsystem) network, an IMS-AGW (IMS access gateway) or MRF (media resource function) can perform the function of a stream termination server. Stream termination parameters can be set by an IMS AS (application server) or an operator's internal equipment configuration protocol. An MTSI (multimedia telephony service for IMS) client located at a terminal can perform the function of a stream termination terminal in an IMS network, and stream termination parameters can be set by a terminal management server such as an application server or OMA DM.

[0152] In the communication system according to the embodiment of the present disclosure, the stream termination setting process of step 4 may include an SDP negotiation process between stream terminations participating in a real-time communication service. For example, when applying PDU Set-based FEC, an RTP payload format media type indicating a specific FEC method and a PT field value of an RTP packet header to be assigned to the RTP payload format media type may be determined through SDP negotiation. In addition, when transmitting protected PDU Set identification information using an RTP extension header, whether a specific RTP extension header expressed as a URI is used and mapping information between the RTP extension header URI to be used and the ID field value of the extension header may be determined through SDP negotiation.

[0153] In one embodiment, the process in which the RTC AF (820) of the above process 903 requests the PCF (113) to allocate resources for a media transmission session may be performed after the stream termination configuration step of the above process 904. At this time, the RTC AF (820) may receive information for configuring the media session QoS parameters of the above-described process 903 from the stream termination (900) (e.g., UE or RTC AS). In one embodiment, the PT field value of the RTP extension header for the above-described FEC may be determined through SDP negotiation between stream terminations, and the negotiation result provided by the stream termination (900) to the RTC AF (820) may be included in a resource allocation request for a media transmission session and transmitted to the PCF (113). In addition, the PCF (113) may transmit the QoS configuration parameters including the SDP negotiation result to another network device (e.g., UPF (850) or RAN (860)).

[0154] FIG. 10 is a flowchart illustrating a procedure for processing a downlink packet for a real-time communication service in a wireless communication system according to one embodiment of the present disclosure.

[0155] Referring to FIG. 10, process 1001 may be a process of generating downlink packets to which PDU Set Marking and FEC are applied at a source stream endpoint (source stream endpoint, 900). The PDU Set Marking and FEC method may be a method set in the service provisioning and media session establishment process described above. Detailed parameters may be determined through dynamic negotiation between stream endpoints before transmitting the actual media stream. Parameters for the dynamic negotiation may be transmitted as protocol messages such as SIP (session initiation protocol) and SDP (session description protocol). The RTC AF (820) may directly or via the NEF (114) transmit the detailed parameters of the PDU Set Marking and FEC method determined through the dynamic negotiation to the PCF (113). The detailed parameters of the PDU Set Marking and FEC method obtained by the PCF (113) may be transmitted to the UPF (850) through the internal information transmission process of 5GS.

[0156] Process 1002 is a process in which a packet transmitted from the stream terminal (900) is delivered to the UPF (850), which serves as a PDU Session Anchor. The stream terminal (900) can transmit DL packets to which PDU Set Marking and FEC are applied to the UPF (850). The UPF (850) can receive DL packets including PDU Set Marking from the stream terminal (900).

[0157] Step 1003 is a step of identifying a PDU Set based on PDU Set Marking in the UPF (850), recognizing the relationship between identified PDU Sets (PDU Set identification), and determining the QoS and packet processing method to be applied to each PDU Set. At this time, FEC repair packets may be regarded as part of the protected PDU Set or processed as a separate PDU Set related thereto. In step 1003, the UPF (850) may add PDU Set-related information to the GTP header for PDU Set-based packet processing of an intermediate UPF (not shown) located on the path to the RAN (860) and the RAN (860).

[0158] Step 1004 is a process of transmitting a packet to the RAN (860) through a GTP (GPRS (General Packet Radio Service) Tunneling Protocol) tunnel. The UPF (850) can transmit a DL GTP-U (user plane) packet to the RAN (860). The RAN (860) can receive a DL GTP-U packet from the UPF (850).

[0159] Step 1005 is a step of performing PDU Set-based packet processing according to the PDU Set of the GTP header and the PDU Set-based FEC configuration information and the policy determined in the media session establishment / modification process in the RAN (860). The PDU Set-based packet processing may include at least one of packet dropping in units of PDU Sets to relieve network congestion, packet scheduling considering the importance of the PDU Set, dropping of associated FEC repair packets when the PDU Set is transmitted without loss, and selective transmission of associated FEC repair packets when packets belonging to the PDU Set are lost.

[0160] In step 1006, the terminal (870) can provide a report including reception information in units of PDU Sets to the stream end (900) that transmitted the downlink media packet.

[0161] The stream end (900) that receives the report including the reception information of the above PDU Set unit can change at least one of the media setting information or the FEC setting information based on the contents of the report (step 1007) or request the PCF (113) to change the QoS setting for the media transmission session through the RTC AF (820) (steps 1008, 1009). The change in the FEC setting information can be, for example, an adjustment of the number of FEC repair packets allocated to the PDU Set.

[0162] FIG. 11 is a flowchart illustrating the operation of a network entity according to one embodiment of the present disclosure.

[0163] The network entity in FIG. 11 may include at least one of an RTC AS (real-time communication application server), an IMS AGW (IMS (IP (internet protocol) multimedia subsystem) access gateway), an MRF (media resource function), or a terminal.

[0164] In one embodiment of the present disclosure, a network entity for forward error correction (FEC) signaling can receive stream termination configuration parameters including the FEC configuration parameters from an RTC real-time communication application function (AF) or an RTC service provider (1110). Furthermore, the network entity can generate an FEC repair packet for a data packet based on the FEC configuration parameters (1120). In one embodiment, the network entity can transmit the data packet and the generated FEC repair packet to a user plane function (UPF) (1130).

[0165] In one embodiment, the FEC configuration parameters may include a real-time transport protocol (RTP) extension header uniform resource indication (URI) that indicates the relationship between the FEC repair packet and the set of packet data units (PDUs) to be protected. Further, in one embodiment, the RTP extension header URI may indicate that the FEC repair packet is based on a single set of packet data units (PDUs), or that the FEC repair packet is based on multiple sets of PDUs.

[0166] In one embodiment, the extension header of the RTP header of the FEC repair packet may include a local identifier associated with the RTP extension header URI, and the value of the local identifier may be determined during a call session negotiation process using SDP (Session Description Protocol), etc. In addition, in one embodiment, the FEC repair packet may include identification information for a PDU set including the data packet.

[0167] FIG. 12 illustrates a structural diagram of a network node according to one embodiment of the present disclosure.

[0168] The network entity illustrated in FIG. 12 may include at least one of an RTC AS (real-time communication application server), an IMS AGW (IMS (IP (internet protocol) multimedia subsystem) access gateway), an MRF (media resource function), or a terminal.

[0169] A network node according to one embodiment of the present disclosure may include a processor (1220) that controls the overall operation of the network node, a transceiver (1200) including a transmitter and a receiver, and a memory (1210). Of course, the present invention is not limited to the above example, and the network node may include more or fewer components than those illustrated in FIG. 12.

[0170] According to one embodiment of the present disclosure, the transceiver (1200) can transmit and receive signals with network entities or other network nodes. The signals transmitted and received with the network entities may include control information and data. In addition, the transceiver (1200) can receive signals via a wireless channel, output them to the processor (1220), and transmit the signals output from the processor (1220) via the wireless channel.

[0171] According to one embodiment of the present disclosure, the processor (1220) can control a network node to perform any one of the operations described above. Meanwhile, the processor (1220), the memory (1210), and the transceiver (1200) do not necessarily have to be implemented as separate modules, and of course, they can be implemented as a single component in the form of a single chip. In addition, the processor (1220) and the transceiver (1200) can be electrically connected. In addition, the processor (1220) can be an Application Processor (AP), a Communication Processor (CP), a circuit, an application-specific circuit, or at least one processor.

[0172] According to one embodiment of the present disclosure, the memory (1210) can store data such as basic programs, application programs, and setting information for the operation of the network node. In particular, the memory (1210) provides the stored data upon request of the processor (1220). The memory (1210) can be configured as a storage medium or a combination of storage media such as a ROM, a RAM, a hard disk, a CD-ROM, and a DVD. In addition, there can be a plurality of memories (1210). In addition, the processor (1220) can perform the above-described embodiments based on a program for performing the above-described embodiments of the present disclosure stored in the memory (1210).

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

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

[0175] These programs (software modules, software) may be stored in a non-volatile memory including random access memory, flash memory, read only memory (ROM), electrically erasable programmable read only memory (EEPROM), magnetic disc storage devices, compact disc ROMs (CD-ROMs), digital versatile discs (DVDs) or other forms of optical storage devices, magnetic cassettes, or may be stored in a memory configured as a combination of some or all of these. In addition, each configuration memory may be included in multiple numbers.

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

[0177] In the specific embodiments of the present disclosure described above, components included in the present disclosure are expressed in the singular or plural form, depending on the specific embodiment presented. However, the singular or plural expressions are selected to suit the presented situation for convenience of explanation, and the present disclosure is not limited to singular or plural components. Components expressed in the plural form may be composed of singular elements, or components expressed in the singular form may be composed of plural elements.

[0178] Meanwhile, the embodiments of the present disclosure disclosed in this specification and drawings are merely specific examples to easily explain the technical contents of the present disclosure and help understand the present disclosure, and are not intended to limit the scope of the present disclosure. In other words, it will be apparent to those skilled in the art that other modified examples based on the technical idea of ​​the present disclosure are possible. In addition, the respective embodiments may be combined and operated as needed. For example, parts of one embodiment of the present disclosure and another embodiment may be combined to operate a base station and a terminal. In addition, the embodiments of the present disclosure are applicable to other communication systems, and other modified examples based on the technical idea of ​​the embodiments may also be implemented. For example, the embodiments may be applied to LTE systems, 5G, or NR systems, etc.

Claims

1. A method of a network entity for FEC (forward error correction) signaling in a wireless communication system, A step of receiving stream termination configuration parameters including FEC configuration parameters; A step of generating an FEC repair packet for a data packet based on the above FEC setting parameters; and A method characterized by comprising the step of transmitting the data packet and the generated FEC repair packet to a UPF (user plane function) entity.

2. In paragraph 1, A method characterized in that the above FEC setting parameters include a uniform resource indication (URI) indicating an RTP (real-time transport protocol) extension header indicating a relationship between the FEC repair packet and a set of PDUs (packet data units) to be protected.

3. In paragraph 2, A method characterized in that the URI indicates that the FEC repair packet is based on a single PDU set, or that the FEC repair packet is based on multiple PDU sets.

4. In paragraph 2, The extension header of the RTP header of the above FEC repair packet is: A method characterized in that it includes a local identifier associated with a URI indicating the RTP extension header.

5. In the second paragraph, the extension header of the RTP header of the FEC repair packet is, Sequence number information of the PDU Set containing the FEC source packet block of the associated FEC repair packet, and A method characterized by including at least one of the serial numbers of PDUs included in the above PDU Set.

6. In paragraph 1, A method characterized in that the FEC repair packet includes identification information for a PDU set including the data packet.

7. In paragraph 1 A method characterized in that the above network entity includes at least one of an RTC AS (real-time communication application server), an IMS AGW (IMS (IP (internet protocol) multimedia subsystem) access gateway), an MRF (media resource function), or a terminal.

8. In paragraph 1, A method characterized in that the above FEC setting parameters are received from an RTC AF (real-time communication application function) or an RTC service provider.

9. In a network entity for FEC (forward error correction) signaling in a wireless communication system, Transmitter and receiver; and comprising at least one processor; wherein the at least one processor comprises: Receive stream termination configuration parameters including FEC configuration parameters, Generate an FEC repair packet for a data packet based on the above FEC setting parameters, A network entity characterized in that it is configured to transmit the data packet and the generated FEC repair packet using a UPF (user plane function).

10. In paragraph 9, A network entity characterized in that the above FEC configuration parameters include a uniform resource indication (URI) indicating an RTP (real-time transport protocol) extension header indicating a relationship between the FEC repair packet and a set of PDUs (packet data units) to be protected.

11. In paragraph 10, A network entity characterized in that the URI indicates that the FEC repair packet is based on a single PDU set, or that the FEC repair packet is based on multiple PDU sets.

12. In Article 10 The extension header of the RTP header of the above FEC repair packet is: A local identifier associated with the URI pointing to the above RTP extension header, Sequence number information of the PDU Set containing the FEC source packet block of the associated FEC repair packet, and A network entity characterized by including at least one of the serial numbers of PDUs included in the above PDU Set.

13. In paragraph 9, A network entity, characterized in that the FEC repair packet includes identification information for a PDU set including the data packet.

14. In Article 9 The above network entity is a network entity characterized in that it includes at least one of an RTC AS (real-time communication application server), an IMS AGW (IMS (IP (internet protocol) multimedia subsystem) access gateway), an MRF (media resource function), or a terminal.

15. In paragraph 9, A network entity characterized in that the above FEC setting parameters are received from an RTC AF (real-time communication application function) or an RTC service provider.

Images