Method and apparatus for media-based round-trip time measurement

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. A method for operation of a first device in a wireless communication system, according to an embodiment of the present disclosure, may comprise the steps of: negotiating a media parameter with a second device by using a session description protocol (SDP); transmitting, to the second device, first real-time transport protocol (RTP) data including a first extension header associated with a round-trip time (RTT); and in response to the first RTP data, receiving, from the second device, second RTP data including a second extension header associated with the RTT, wherein the SDP for the negotiation for the media parameter includes information for associating the first extension header with the second extension header.

Description

Method and device for measuring media-based round-trip time

[0001] The present disclosure relates to a wireless communication system, and more particularly, to a method and device for measuring round-trip time 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 seeks to provide a device and method capable of effectively providing real-time communication services in a wireless communication system.

[0010] According to one embodiment of the present disclosure, a method of operating a first device of a wireless communication system includes the steps of: negotiating media parameters with a second device using a Session Description Protocol (SDP); transmitting, to the second device, first Real-Time Transport Protocol (RTP) data including a first extension header associated with a round-trip time (RTT); and receiving, in response to the first RTP data, second RTP data including a second extension header associated with the RTT from the second device; wherein the SDP for media parameter negotiation may include information for associating the first extension header and the second extension header.

[0011] According to one embodiment of the present disclosure, a method of operating a second device of a wireless communication system includes the steps of: negotiating media parameters with a first device using a Session Description Protocol (SDP); receiving, from the first device, first Real-Time Transport Protocol (RTP) data including a first extension header associated with a round-trip time (RTT); and transmitting, in response to the first RTP data, second RTP data including a second extension header associated with the RTT to the first device; wherein the SDP for media parameter negotiation may include information for associating the first extension header with the second extension header.

[0012] According to one aspect of one embodiment of the present disclosure, a first device is provided, comprising: a transceiver; and at least one control unit coupled to the transceiver, wherein the at least one control unit negotiates media parameters with a second device using a Session Description Protocol (SDP), transmits to the second device first RTP (Real-Time Transport Protocol) data including a first extension header associated with a round-trip time (RTT), and transmits, in response to the first RTP data, second RTP data including a second extension header associated with the RTT from the second device, wherein the SDP for media parameter negotiation includes information for associating the first extension header and the second extension header.

[0013] According to one aspect of one embodiment of the present disclosure, a second device is provided, comprising: a transceiver; and at least one control unit coupled to the transceiver, wherein the at least one control unit negotiates media parameters with a first device using a Session Description Protocol (SDP), receives from the first device first RTP (Real-Time Transport Protocol) data including a first extension header associated with a round-trip time (RTT), and transmits, in response to the first RTP data, second RTP data including a second extension header associated with the RTT to the first device, wherein the SDP for media parameter negotiation includes information for associating the first extension header with the second extension header.

[0014] A method performed by a first media transceiver in a wireless communication system according to one embodiment of the present disclosure may include the steps of: transmitting a round-trip time (RTT) measurement request to a second media transceiver; receiving an RTT measurement response from the second media transceiver; and calculating a media-based RTT based on the RTT measurement request and the RTT measurement response.

[0015] According to one embodiment of the present disclosure, the RTT measurement request and RTT measurement response may be included in a packet transmitting media data of a media service.

[0016] The technical problems to be achieved in various embodiments of the present disclosure are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art to which the present invention pertains from the description below.

[0017] According to one embodiment of the present disclosure, a real-time communication service can be effectively provided in a mobile communication system.

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

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

[0020] FIG. 2 is a diagram illustrating an example of a method for measuring RTT (Round Trip Time) in a wireless communication system according to an embodiment of the present disclosure.

[0021] FIG. 3 is a diagram illustrating a media-based RTT measurement method according to one embodiment of the present disclosure.

[0022] FIG. 4 is a diagram illustrating an example of a media transmission packet structure in a wireless communication system according to an embodiment of the present disclosure.

[0023] FIG. 5 is a diagram illustrating the relationship between a media transmission session and an RTP stream that constitute a real-time communication service in a wireless communication system according to an embodiment of the present disclosure.

[0024] FIG. 6 is a diagram illustrating an example of an RTT request extension header according to one embodiment of the present disclosure.

[0025] FIG. 7 is a diagram illustrating an example of an RTT response extension header according to one embodiment of the present disclosure.

[0026] FIG. 8 is a diagram illustrating an example of an RTT request extension header according to one embodiment of the present disclosure.

[0027] FIG. 9 is a diagram illustrating an example of an RTT response extension header according to one embodiment of the present disclosure.

[0028] FIG. 10 is a diagram illustrating the structure of a device according to an embodiment of the present disclosure.

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

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

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

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

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

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

[0035] 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. An embodiment of the present disclosure will be described below with reference to the attached drawings.

[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. Singular expressions 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 one embodiment 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, embodiments of the present disclosure can be applied to other communication systems with similar technical backgrounds or channel types. Furthermore, an embodiment 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] RTT (Round Trip Time) can mean the time it takes for a packet to be transmitted from the sender to the receiver via any number of intermediate ports or communication networks, and for the response signal to reach the sender via multiple intermediate ports or communication networks again. At this time, RTT can include the request processing time, which is the time it takes for the receiver to process the request received, generate the response, and transmit it. The request processing time can vary depending on the system layer that processes the RTT measurement request. For example, when measuring the RTT of an IP packet using ICMP (Internet Control Message Protocol), the request processing time can be the time it takes for the receiver to generate and transmit an ICMP echo reply in response to an ICMP echo request received by the receiver. As another example, in TCP (Transmission Control Protocol), the request processing time can be the time it takes for the receiver to generate and transmit an acknowledgment after receiving a sample segment for RTT measurement transmitted by the sender.

[0045] The RTT measurement methods described above operate based on client-server transactions. Therefore, they are difficult to apply to real-time communication services, where service participants continuously exchange real-time media data. Furthermore, it is desirable for the request processing time of real-time communication services to include media processing time, not just packet processing time.

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

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

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

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

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

[0051] Additionally, 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 circumstances. 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. In addition, a network slice may be implemented for various purposes.

[0052] Referring to Fig. 1, examples of interfaces between each node are illustrated. 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), a 5G RTC WSF (122), and a 5G RTC AS (123) located in a DN (data network). The interfaces between the RTC AF (121) and the RTC AS (122) and the UE will be described in more detail in the description of the media architecture to be described later.

[0053] FIG. 2 is a diagram illustrating an example of a method for measuring RTT (Round Trip Time) in a wireless communication system according to an embodiment of the present disclosure.

[0054] Referring to Figure 2, it can be assumed that the client (210) and server (220) are synchronized to the same reference time and can exchange packets via a network (230). The network (230) may be, for example, 5GS. In this case, the RTT can be measured using the following procedure:

[0055] - The client (210) transmits an RTT measurement request to the server (220) at time t1.

[0056] - The server (220) receives the RTT measurement request transmitted at time t1 at time t2.

[0057] - The server (220) transmits a response to the RTT measurement request received at time t2 to the client (210) at time t3.

[0058] - The client (210) receives a response to the RTT measurement request transmitted at time t1 at time t4.

[0059] - The client (210) calculates RTT as the difference between time t4 and time t1.

[0060] The RTT may include a request processing time, which is the time it takes for the server (220) to process a received request, generate a response, and transmit it. For example, the RTT of FIG. 2 may include a request processing time t3 - t2, which is the time it takes for the server (220) to process an RTT measurement request, generate a response, and transmit it after receiving the request. The request processing time may vary depending on the system layer that processes the RTT measurement request. For example, when measuring the RTT of an IP packet using ICMP (Internet Control Message Protocol), the request processing time may be the time it takes for the server (220) to generate and transmit an ICMP echo reply in response to an ICMP echo request received. As another example, in TCP (Transmission Control Protocol), the request processing time may be the time it takes for the server (220) to generate and transmit an acknowledgment after receiving a sample segment for RTT measurement transmitted by a client (210).

[0061] Real-time communication services, such as voice calls that transmit media using RTP (Real-Time Transport Protocol), can measure RTT using RTCP (RTP control protocol). RTCP-based RTT measurement can be performed using RTCP Sender Report (SR) and Receiver Report (RR), but in this case, the request processing time may include a waiting time to comply with the report transmission cycle. Since the report transmission cycle may be affected by factors that the server (220) cannot control, such as the bandwidth allocated to RTCP and the number of users participating in the RTP session, when measuring RTT using RTCP, only the packet round-trip time excluding the request processing time may be considered.

[0062] The RTT measurement methods described above can operate based on client-server transactions. Therefore, they may be difficult to apply to real-time communication services, where service participants continuously exchange real-time media data. Furthermore, it may be desirable for the request processing time of real-time communication services to include media processing time, rather than simple packet processing time.

[0063] FIG. 3 is a diagram illustrating a media-based RTT measurement method according to one embodiment of the present disclosure.

[0064] Referring to FIG. 3, device A (310) and device B (320) participate in a real-time service through applications (311, 321) running on each device, and can exchange requests and responses for actual media data and RTT measurement through a media transmission device (312, 322).

[0065] In a media-based RTT measurement method according to one embodiment of the present disclosure, an application providing a real-time service can negotiate media-based RTT measurement parameters during a media session setup process. The media-based RTT measurement parameters may include, for example, at least one of the role of each device (client or server), a processing identifier for measuring request processing time, an input media identifier of a processing identified by the processing identifier, and an output media identifier.

[0066] In a media-based RTT measurement method according to an embodiment of the present disclosure, a real-time communication service may include one or more media-based RTT measurement sessions, and the role of the device may be determined differently for each media-based RTT measurement session. The media-based RTT measurement session may be defined by at least one of a client device, a server device, a processing identifier, an input media identifier, and an output media identifier, for example.

[0067] In a media-based RTT measurement method, a media transmission device (312, 322) can transmit media data including an RTT measurement request or response depending on its role. In an embodiment according to this drawing, a media-based RTT measurement session may be assumed, for example, in which device A (310) acts as a client and device B (320) acts as a server.

[0068] Referring to FIG. 3, a media transmission device (312) of device A (310) can transmit an RTT request media packet including an RTT request to a media stream identified by an input media identifier. Media data included in the media packet together with the RTT request can be referred to as request media data. A media transmission device (322) of device B (320) that receives the RTT request media packet can initiate measurement of a request processing time and transmit the request media data to an application program (321).

[0069] The result of processing the request media data received by the application (321) using a processing identifier can be referred to as response media data. The media transmission device (322) of the device B (320) can transmit an RTT response media packet including the response media data and an RTT response (RTT response) to the output media stream. The device A (310) that receives the RTT response media packet can calculate the RTT as the difference between the reception time of the RTT response media packet and the transmission time of the corresponding RTT request media packet.

[0070] The RTT request media packet may include information about the time at which the RTT request media packet was transmitted, which may be used by device B (320) that received the RTT request media packet to measure a media transmission delay time between device A (310) and device B (320). Similarly, the RTT response media packet may include information about the time at which the RTT response media packet was transmitted, which may be used by device A (310) that received the RTT response media packet to measure a media transmission delay time between device B (320) and device A (310). At least one of the RTT request media packet and the RTT response media packet may include a processing identifier.

[0071] The RTT value calculated in the above-described manner may include the request processing time of device B (320). In the RTT measurement method according to one embodiment of the present disclosure, the request processing time may be calculated as the difference between the time at which the media transmission device (322) of device B (320) transmits the RTT response media packet and the time at which the RTT request media packet is received. For example, the request processing time may be regarded as the time until device B (320) processes the request media data and generates the response media data.

[0072] According to one embodiment of the present disclosure, the requested media data may be transmitted as one or more media packets, depending on the type of media and processing method. Furthermore, since the application program may include one or more processing operations, the requested media data may be transmitted to a processing unit identified by a processing identifier after undergoing one or more preprocessing operations. Furthermore, the response media data, which is the result of the processing, may also be transmitted to the media transmission device after undergoing one or more postprocessing operations.

[0073] In an RTT measurement method according to an embodiment of the present disclosure, an RTT response media packet may include information related to a request processing time. The request processing time-related information may, for example, indicate a value of the request processing time, or include at least one parameter or a combination thereof capable of calculating the request processing time. The combination of at least one parameter capable of calculating the request processing time may be a combination of the time at which the RTT request media packet is received and the time at which the RTT response media packet is transmitted. In addition, the request processing time-related information may further include time information related to the aforementioned preprocessing and postprocessing.

[0074] In a real-time communication service supporting media-based RTT measurement according to one embodiment of the present disclosure, media data may be transmitted using RTP, and RTT requests and RTT responses may be transmitted using RTP extension headers. In this case, media-based RTT measurement parameters may be negotiated between service participants using SDP (Session Description Protocol).

[0075] FIG. 4 is a diagram illustrating an example of a media transmission packet structure in a wireless communication system according to an embodiment of the present disclosure.

[0076] Referring to FIG. 4, an RTP header (420), a UDP header (430), and an IP header (440) may be added to transmit an RTP payload (410) including media data. The RTP header (420) may include an RTP extension header. Referring to FIG. 4, the first 12 octets or 12 bytes of the RTP header (420) are included in all RTP packets, and CSRC identifiers may be added by an RTP middle box such as a mixer. The RTP header (420) may include at least one of the fields described below. In addition, the values ​​set in each field and / or the bit length of each field are merely examples for the convenience of understanding, and the scope of the present disclosure is not limited by specific values.

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

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

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

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

[0081] - marker (M): A 1-bit field whose usage can be determined by the RTP profile. For example, when one video frame is divided into multiple RTP packets and transmitted, only the M field value of the last RTP packet among the RTP packets can be set to 1.

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

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

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

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

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

[0087] 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). Accordingly, packets in which the RTP / UDP / IP protocol is used, as shown in the packet in FIG. 4, and in which the source / destination IP address values ​​of the IP header (440) and the source / destination port number values ​​of the UDP header (430) 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.

[0088] FIG. 5 is a diagram illustrating the relationship between a media transmission session and an RTP stream that constitute a real-time communication service in a wireless communication system according to an embodiment of the present disclosure.

[0089] Referring to Fig. 5, it can be assumed that the IP addresses of devices A (510) and B (511) participating in a real-time communication service are, for example, 192.168.0.1 and 192.168.0.21, respectively. The real-time communication service may be composed of, for example, four media streams, and each media stream may be transmitted as an associated RTP stream (521, 522, 523, 524).

[0090] In a media-based RTT measurement method according to an embodiment of the present disclosure, an RTT measurement request and response may be transmitted through the same media transmission session. For example, a first RTP stream (521) and a second RTP stream (522) may be transmitted through a first media transmission session (531), and a port number of device A (510) of the first media transmission session (531) may be, for example, 16384, and a port number of device B (511) may be, for example, 18472.

[0091] In this example, the first RTP stream (521) may be defined as an RTP packet flow having a source IP address and a source port number (source transmission address) of 192.168.0.1:16384, a destination IP address and a destination port number (destination transmission address) of 192.168.0.21:18472, and the same SSRC field value (for example, 0x38a95a7e). In addition, the second RTP stream (522) may be defined as an RTP packet flow having a source transmission address and a destination transmission address of 192.168.0.21:18472 and 192.168.0.1:16384, respectively, and the same SSRC field value (for example, 0x8ecd3af7). In this case, a media-based RTT measurement session according to an embodiment of the present disclosure may be configured by at least one of the following:

[0092] - RTT measurement client: Device A (192.168.0.1)

[0093] - RTT measurement server: Device B (192.168.0.21)

[0094] - Input media identifier: source transport address 192.168.0.1: 16384, destination transport address 192.168.0.21: 18472, SSRC = 0x38a95a7e, and at least one of the separate identifiers.

[0095] - Output media identifier: source transport address 192.168.0.21:18472, destination transport address 192.168.0.1:16384, SSRC = 0x8ecd3af7, and at least one of the separate identifiers.

[0096] - Processing identifier

[0097] As another example, a media-based RTT measurement session for a first media transmission session (531) may be configured by at least one of the following:

[0098] - RTT measurement client: Device B (192.168.0.21)

[0099] - RTT measurement server: Device A (192.168.0.1)

[0100] - Input media identifier: source transport address 192.168.0.21:18472, destination transport address 192.168.0.1:16384, SSRC = 0x8ecd3af7, and at least one of the separate identifiers.

[0101] - Output media identifier: source transport address 192.168.0.1: 16384, destination transport address 192.168.0.21: 18472, SSRC = 0x38a95a7e, and at least one of the separate identifiers.

[0102] - Processing identifier

[0103] In a media-based RTT measurement method according to an embodiment of the present disclosure, an RTT measurement request and a response may be transmitted through different media transmission sessions. For example, a third RTP stream (523) may be transmitted through a second media transmission session (532), and a port number of device A (510) of the second media transmission session (532) may be, for example, 24532, and a port number of device B (511) may be, for example, 25762. In addition, a fourth RTP stream (524) may be transmitted through a third media transmission session (533), and a port number of device A (510) of the third media transmission session (533) may be, for example, 30146, and a port number of device B (511) may be, for example, 31082.

[0104] In this example, the third RTP stream (523) may be defined as an RTP packet flow having source and destination transmission addresses of 192.168.0.1:24532 and 192.168.0.21:25762, respectively, and the same SSRC field value (e.g., 0x54c8bd21). In addition, the fourth RTP stream (524) may be defined as an RTP packet flow having source and destination transmission addresses of 192.168.0.21:31082 and 192.168.0.1:30146, respectively, and the same SSRC field value (e.g., 0x8ecd3af7). In this case, a media-based RTT measurement session according to an embodiment of the present disclosure may be configured by at least one of the following:

[0105] - RTT measurement client: Device A (192.168.0.1)

[0106] - RTT measurement server: Device B (192.168.0.21)

[0107] - Input media identifier: source transport address 192.168.0.1: 24532, destination transport address 192.168.0.21: 25762, SSRC = 0x54c8bd21, and at least one of the separate identifiers.

[0108] - Output media identifier: source transport address 192.168.0.21: 31082, destination transport address 192.168.0.1: 30146, SSRC = 0x8ecd3af7, and at least one of the separate identifiers.

[0109] - Processing identifier

[0110] As another example, the media-based RTT measurement session for the second media transfer session (532) and the third media transfer session (533) may be configured by at least one of the following:

[0111] - RTT measurement client: Device B (192.168.0.21)

[0112] - RTT measurement server: Device A (192.168.0.1)

[0113] - Input media identifier: source transport address 192.168.0.21: 31082, destination transport address 192.168.0.1: 30146, SSRC = 0x8ecd3af7, and at least one of the separate identifiers.

[0114] - Output media identifier: source transport address 192.168.0.1:24532, destination transport address 192.168.0.21:25762, SSRC = 0x54c8bd21, and at least one of the separate identifiers.

[0115] - Processing identifier

[0116] In the embodiments described above, a separate identifier that can be used as an input media identifier or output media identifier parameter value can be negotiated when performing a session establishment procedure using SDP, etc. For example, the value of the "a=label:" attribute, which is a sub-attribute of the media description (m-line) included in SDP, can be used as the input media or output media identifier.

[0117] Meanwhile, the RTP extension header can consist of a header and extension data. Here, the header can be 1 byte (One-Byte Header Form) or 2 bytes (Two-Byte Header Form) in length and can include ID and length fields. The format of the extension data portion can be specified by a Uniform Resource Identifier (URI).

[0118] The above ID field represents a local identifier of the RTP extension header, and its length can be 4 bits in One-Byte Header Form and 8 bits in Two-Byte Header Form. The mapping between the local identifier and the URI can be negotiated when performing a session establishment procedure using SDP, etc. The above length field can represent a value obtained by subtracting 1 from the byte length of the following extension data with a 4-bit length in One-Byte Header Form, and can represent the byte length of the following extension data with an 8-bit length in Two-Byte Header Form.

[0119] FIG. 6 is a diagram illustrating an example of an RTT request extension header according to one embodiment of the present disclosure.

[0120] For example, the URI of the RTP extension header of FIG. 6 may be defined in a format including "urn:3gpp:rtt-measurement-request". Referring to FIG. 6, the extension header may include at least one of the following fields:

[0121] - sending timestamp: The time when the RTP packet (RTT request media packet) containing this RTP extension header was sent from the RTT measurement client. This can be a counter value based on NTP or the system clock.

[0122] - processing type: An identifier indicating the processing for measuring request processing time. The specific meaning can be defined by the application. For example, a value of 0x00 can indicate that the media-based RTT measurement server receives an RTT request media packet and immediately generates and transmits an RTT response media packet. This field may be optional, and its presence can be negotiated during session establishment procedures such as using SDP.

[0123] FIG. 7 is a diagram illustrating an example of an RTT response extension header according to one embodiment of the present disclosure.

[0124] For example, the URI of the RTP extension header in FIG. 7 may be defined in a format including "urn:3gpp:rtt-measurement-response." Referring to FIG. 7, the extension header may include at least one of the following fields:

[0125] - response sending timestamp: The time when the RTP packet (RTT response media packet) containing this RTP extension header was transmitted from the RTT measurement server. This can be a counter value based on NTP or the system clock.

[0126] - request sending timestamp: The time at which the RTP request media packet associated with this RTT response media packet was transmitted. For example, the value of the sending timestamp field in the associated RTP request media packet.

[0127] - request receiving timestamp: The time when the RTT request media packet associated with this RTT response media packet was received by the RTT measurement server.

[0128] - processing type: An identifier indicating the processing for measuring request processing time. The specific meaning can be defined by the application. For example, a value of 0x00 can indicate that the media-based RTT measurement server receives an RTT request media packet and immediately generates and transmits an RTT response media packet. This field may be optional, and its presence can be negotiated during session establishment procedures such as using SDP.

[0129] An RTT measurement client that receives an RTT response extension header defined in a format including the above "urn:3gpp:rtt-measurement-response" can obtain at least one piece of RTT and transmission time-related information using the timestamp values ​​of the RTT response extension header.

[0130] ■ T4 - T1 = RTT

[0131] ■ T3 - T2 = Request processing time

[0132] ■ T2 - T1 = Packet transmission time from the RTT measurement client to the RTT measurement server

[0133] ■ T4 - T3 = Packet transmission time from RTT measurement server to RTT measurement client

[0134] Here, T1 is a request sending timestamp value, T2 is a request receiving timestamp value, T3 is a response sending timestamp value, and T4 may mean a time when the RTT measurement client received an RTP packet including the RTT response extension header.

[0135] An RTT measurement client according to an embodiment of the present disclosure can use the request sending timestamp value of the RTT response extension header to determine whether the RTT response extension header is a valid response to the RTT request extension header transmitted by the actual RTT measurement client.

[0136] FIG. 8 is a diagram illustrating an example of an RTT request extension header according to one embodiment of the present disclosure.

[0137] For example, the URI of the RTP extension header of FIG. 8 may be defined in a format including "urn:3gpp:rtt-measurement-request-transid." Referring to FIG. 8, the extension header may include at least one of the following fields:

[0138] - sending timestamp: The time when the RTP packet (RTT request media packet) containing this RTP extension header was sent from the RTT measurement client. This can be a counter value based on NTP or the system clock.

[0139] - Transaction ID: Transaction identifier including the corresponding RTT request extension header. The transaction may be comprised of transmitting an RTP packet including the RTT request extension header and receiving an RTP packet including the corresponding RTT response extension header.

[0140] - processing type: An identifier indicating the processing for measuring request processing time. The specific meaning can be defined by the application. For example, a value of 0x00 can indicate that the media-based RTT measurement server receives an RTT request media packet and immediately generates and transmits an RTT response media packet. This field may be optional, and its presence can be negotiated during session establishment procedures such as using SDP.

[0141] FIG. 9 is a diagram illustrating an example of an RTT response extension header according to one embodiment of the present disclosure.

[0142] For example, the URI of the RTP extension header of FIG. 9 may be defined in a format including "urn:3gpp:rtt-measurement-response-transid". Referring to FIG. 9, the extension header may include at least one of the following fields:

[0143] - response sending timestamp: The time when the RTP packet (RTT response media packet) containing this RTP extension header was transmitted from the RTT measurement server. This can be a counter value based on NTP or the system clock.

[0144] - transaction ID: Transaction identifier containing the corresponding RTT response extension header. It may have the same value as the transaction ID of the associated RTT request extension header.

[0145] - request receiving timestamp: The time when the RTT measurement server received the RTP request media packet (with the same transaction ID value in the RTT request extension header) associated with this RTT response media packet.

[0146] - processing type: An identifier indicating the processing for measuring request processing time. The specific meaning can be defined by the application. For example, a value of 0x00 can indicate that the media-based RTT measurement server receives an RTT request media packet and immediately generates and transmits an RTT response media packet. This field may be optional, and its presence can be negotiated during session establishment procedures such as using SDP.

[0147] An RTT measurement client that receives an RTT response extension header defined in a format including the above "urn:3gpp:rtt-measurement-response-transid" can obtain at least one piece of RTT and transmission time-related information using the timestamp values ​​of the RTT response extension header.

[0148] ■ T4 - T1 = RTT

[0149] ■ T3 - T2 = Request processing time

[0150] ■ T2 - T1 = Packet transmission time from RTT measurement client to RTT measurement server

[0151] ■ T4 - T3 = Packet transmission time from RTT measurement server to RTT measurement client

[0152] Here, T1 may refer to the time at which the RTT measurement client transmitted an RTP packet including an RTT request extension header having the same value as the transaction ID of the RTT response extension header, T2 may refer to the request receiving timestamp value, T3 may refer to the response sending timestamp value, and T4 may refer to the time at which the RTT measurement client received the RTP packet including the RTT response extension header.

[0153] In another embodiment of the RTT response extension header illustrated in FIG. 9, the request receiving timestamp may be replaced with another value that enables calculation of the RTT, request processing time, packet transmission time from the RTT measurement client to the RTT measurement server, and / or packet transmission time from the RTT measurement server to the RTT measurement client. For example, the request receiving timestamp may be provided as a client to server transmission delay indicating a packet transmission time from the RTT measurement server to the RTT measurement client, or a processing time indicating a request processing time of the RTT measurement server.

[0154] In a media-based RTT measurement method according to an embodiment of the present disclosure, parameters related to the RTT measurement session may be determined during the SDP negotiation process. For example, the m-line (media description) of the negotiated SDP may include at least one of the following extmap attributes.

[0155] a = extmap: <value> [" / " <direction> ] <uri> <extensionattributes>

[0156] - <value> : <uri>The value of the ID field of the extended header identified by (local identifier)

[0157] - <direction>: can have values ​​"sendonly", "recvonly", "sendrecv", or "inactive"

[0158] - <uri>: URI for identifying extended headers

[0159] - <extensionattributes>: Extension header settings information

[0160] In the parameter negotiation process for media-based RTT measurement according to one embodiment of the present disclosure, <direction>Parameters can be defined as shown in [Table 1].

[0161] sendonlyrecvonlysendrecvRTT request extension headersRTT measurement client roleRTT measurement server roleRTT measurement server / client roleRTT response extension headersRTT measurement server roleRTT measurement client role

[0162] In the parameter negotiation process for media-based RTT measurement according to one embodiment of the present disclosure, <extensionattributes>The parameter may include information for associating an RTT request RTP stream and an RTT response RTP stream. The RTT request RTP stream may refer to an RTP stream to which an RTP packet including an RTT request extension header belongs, and the RTT response RTP stream may refer to an RTP stream to which an RTP packet including an RTT response extension header belongs. The RTT request / response RTP stream may refer to all RTP streams described in a media description (m-line) to which an a=extmap attribute setting an RTT request / response extension header belongs, or may refer to only streams having a specific SSRC field value.

[0163] For example, the above <extensionattributes>The parameter may include an RTT measurement session identifier. The RTT measurement session identifier may be a separately assigned value or at least one of the "a=label:" attribute value and the SSRC value of the media description (m-line) containing the a=extmap attribute.

[0164] In the parameter negotiation process for media-based RTT measurement according to one embodiment of the present disclosure, <extensionattributes>The parameter may include processing-related information for the request processing time. For example, the processing-related information may be a list of processing identifiers associated with the corresponding RTT measurement session. If the processing-related information provides a single processing identifier, the processing type parameter may be omitted from the RTT request / response header described above.

[0165] As an example, the above <extensionattributes>Parameters can be defined as shown in Table 2 below.

[0166] extensionattributes = format[";"ssrc][";" rttsession*2(";"rttsession)][";"processingtype]format = "short" / "long" / "shortlong"ssrc = "ssrc=" ssrc-idssrc-id = integer; 0 .. 2**32 - 1rttsession = rttsessionid / requestlabel / responselabelrttsessionid = "rttsessionid=" zeroto255requestlabel = "reqlabel=" token [;"reqssrc"=ssrc-id]responselabel = "resplabel=" token [;"respssrc"=ssrc-id]processingtype = "processtype=" processtypevalueprocesstyepvalue = "all" / processtypelistprocesstypelist = processtypevalue *(","processtypevalue)processtypevalue = zeroto255; 0..255

[0167] The format parameter of the above [Table 2] having a value of "shortlong" may mean that the header of the RTP extension header described by the associated extmap attribute can be selectively used as either 1 byte (One-Byte Header Form) or 2 bytes (Two-Byte Header Form). In another embodiment, when the length of the RTP extension header described by the associated extmap attribute is not specified, the format parameter may be omitted instead of having a value of "shortlong".

[0168] For example, the RTT measurement sessions of FIG. 5 described above can be defined in the SDP proposal of Device A (510) as shown in Table 3 below.

[0169] m=video 16384a=sendrecva=extmap:1 / sendonly urn:3gpp:rtt-measurement-request shorta=extmap:2 / recvonly urn:3gpp:rtt-measurement-response shortm=audio 24532a=sendonlya=extmap:1 / sendonly urn:3gpp:rtt-measurement-request short; rttsessionid=1;processtype=allm=video 30146a=recvonlya=extmap:1 / sendonly urn:3gpp:rtt-measurement-response short; rttsessionid=1;processtype=all

[0170] As another example, the RTT measurement sessions of FIG. 5 described above can be defined in the SDP proposal of Device B (511) as shown in Table 4 below.

[0171] m=video 18472label=mainvideoa=sendrecva=extmap:1 / sendonly urn:3gpp:rtt-measurement-request short;resplabel= mainvideo;processingtype=1a=extmap:2 / recvonly urn:3gpp:rtt-measurement-response short;reqlabel= mainvideo;processingtype=1m=audio 25762label=inputaudioa=recvonlya=extmap:1 / recvonly urn:3gpp:rtt-measurement-request short; resplabel= outputvideo;processtype=2m=video 31082label=outputvideoa=sendonlya=extmap:1 / sendonly urn:3gpp:rtt-measurement-response short; reqlabel=inputaudio;processtype=2

[0172] FIG. 10 is a diagram illustrating the structure of a device according to an embodiment of the present disclosure.

[0173] For example, the device may mean any one of the RTT measurement client or RTT measurement server described in FIGS. 1 to 9 above.

[0174] Referring to FIG. 10, the device may include a transceiver (10-05), a control unit (10-10), and a storage unit (10-15). The transceiver (10-05), the control unit (10-10), and the storage unit (10-15) may operate according to the communication method of the device described above. However, the components of the device are not limited to the examples described above. For example, the device may include more or fewer components than the components described above. For example, the device may include a transceiver (10-05) and a control unit (10-10). In addition, the transceiver (10-05), the control unit (10-10), and the storage unit (10-15) may be implemented in the form of a single chip.

[0175] The transceiver (10-05) is a general term for the receiver and transmitter of the device, and can transmit and receive signals with other devices (e.g., an RTT measurement server or an RTT measurement client). To this end, the transceiver (10-05) may be configured with an RF transmitter that up-converts and amplifies the frequency of a transmitted signal, and an RF receiver that low-noise amplifies and frequency-converts the received signal. However, this is only one embodiment of the transceiver (10-05), and the components of the transceiver (10-05) are not limited to the RF transmitter and RF receiver. In addition, the transceiver (10-05) may include a wired / wireless transceiver (10-05), and may include various configurations for transmitting and receiving signals. In addition, the transceiver (10-05) may receive a signal through a wireless channel, output it to the control unit (10-10), and transmit a signal output from the control unit (10-10) through the wireless channel. In addition, the transceiver (10-05) can receive a communication signal and output it to the processor, and transmit the signal output from the processor to a network entity via a wired or wireless network.

[0176] The storage unit (10-15) can store programs and data necessary for the operation of the device. In addition, the memory can store control information or data included in signals acquired from the device. The storage unit (10-15) can be configured as a storage medium or a combination of storage media, such as a ROM, RAM, hard disk, CD-ROM, and DVD.

[0177] In the present disclosure, the control unit (10-10) may be defined as a circuit or application-specific integrated circuit or at least one processor. The processor may include a communication processor (CP) that performs control for communication and an application processor (AP) that controls upper layers such as application programs. The control unit (10-10) may control the overall operation of the device according to the embodiment proposed in the present disclosure. For example, the control unit (10-10) may control the signal flow between each block to perform operations according to the flowchart described above. 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.

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

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

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

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

[0182] 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 modifications based on the technical idea of ​​the present disclosure are possible. In addition, the above-mentioned embodiments can be combined and operated with each other as needed. For example, parts of one embodiment of the present disclosure and another embodiment can be combined with each other to operate a base station and a terminal. In addition, the embodiments of the present disclosure can be applied to other communication systems, and other modifications based on the technical idea of ​​the embodiments can also be implemented. For example, the embodiments can be applied to LTE systems, 5G, or NR systems, etc.< / extensionattributes> < / extensionattributes> < / extensionattributes> < / extensionattributes> < / direction> < / extensionattributes> < / uri> < / direction> < / uri> < / value> < / extensionattributes> < / uri> < / direction> < / value>

Claims

1. In a method of operating a first device in a wireless communication system, A step of negotiating media parameters with a second device using SDP (Session Description Protocol); A step of transmitting first RTP (Real-Time Transport Protocol) data including a first extension header associated with RTT (round-trip time) to the second device; and In response to the first RTP data, the method comprises receiving, from the second device, second RTP data including a second extension header associated with the RTT; A method, characterized in that the SDP for the above media parameter negotiation includes information for associating the first extension header and the second extension header.

2. In paragraph 1, A method wherein the SDP further includes at least one of an attribute value capable of identifying a media description (m-line) describing information about a stream corresponding to the first RTP data and processing information about the first RTP data.

3. In paragraph 1, A method wherein the first extension header includes information indicating the time at which the first device transmits the first RTP data to the second device.

4. In paragraph 1, The above second extension header is, Information indicating the time at which the first device transmits the first RTP data to the second device; Information indicating the time at which the second device receives the first RTP data from the first device, and Information indicating the time at which the second device transmits the second RTP data to the first device A method comprising:

5. In a method of operating a second device in a wireless communication system, A step of negotiating media parameters using the first device and Session Description Protocol (SDP); A step of receiving first RTP (Real-Time Transport Protocol) data including a first extension header associated with a round-trip time (RTT) from the first device; and In response to the first RTP data, the method comprises the step of transmitting, to the first device, second RTP data including a second extension header associated with the RTT; A method, characterized in that the SDP for the above media parameter negotiation includes information for associating the first extension header and the second extension header.

6. In paragraph 5, A method wherein the SDP further includes at least one of an attribute value capable of identifying a media description (m-line) describing information about a stream corresponding to the first RTP data and processing information about the first RTP data.

7. In paragraph 5, A method wherein the first extension header includes information indicating the time at which the first device transmits the first RTP data to the second device.

8. In paragraph 5, The above second extension header is, Information indicating the time at which the first device transmits the first RTP data to the second device; Information indicating the time at which the second device receives the first RTP data from the first device, and Information indicating the time at which the second device transmits the second RTP data to the first device A method comprising:

9. In a first device in a wireless communication system, Transmitter and receiver; and At least one control unit coupled to the above transceiver unit, At least one of the above control units, Negotiate media parameters with the second device using Session Description Protocol (SDP), To the second device, transmit first RTP (Real-Time Transport Protocol) data including a first extension header associated with RTT (round-trip time), In response to the first RTP data, transmit second RTP data including a second extension header associated with the RTT from the second device, A first device, characterized in that the SDP for the media parameter negotiation includes information for associating the first extension header and the second extension header.

10. In paragraph 9, A first device, wherein the SDP for the media parameter negotiation further includes at least one of an attribute value capable of identifying a media description (m-line) describing information about a stream corresponding to the first RTP data and processing information about the first RTP data.

11. In paragraph 9, A first device, wherein the first extension header includes information indicating the time at which the first device transmits the first RTP data to the second device.

12. In paragraph 9, The above second extension header is, Information indicating the time at which the first device transmits the first RTP data to the second device; Information indicating the time at which the second device receives the first RTP data from the first device, and Information indicating the time at which the second device transmits the second RTP data to the first device A first device comprising:

13. In a second device in a wireless communication system, Transmitter and receiver; and At least one control unit coupled to the above transceiver unit, At least one of the above control units, The first device negotiates media parameters using the Session Description Protocol (SDP), Receive from the first device first RTP (Real-Time Transport Protocol) data including a first extension header associated with a round-trip time (RTT), In response to the first RTP data, transmitting to the first device second RTP data including a second extension header associated with the RTT, A second device, characterized in that the SDP for the media parameter negotiation includes information for associating the first extension header and the second extension header.

14. In paragraph 13, A second device, wherein the SDP further includes at least one of an attribute value capable of identifying a media description (m-line) describing information about a stream corresponding to the first RTP data and processing information about the first RTP data.

15. In paragraph 13, The first extension header includes information indicating the time at which the first device transmits the first RTP data to the second device, The above second extension header is, Information indicating the time at which the first device transmits the first RTP data to the second device; Information indicating the time at which the second device receives the first RTP data from the first device, and Information indicating the time at which the second device transmits the second RTP data to the first device A second device comprising:

Images