WO2018021734A1 - 무선 통신 시스템에서 데이터의 전송 방법 및 장치 - Google Patents

무선 통신 시스템에서 데이터의 전송 방법 및 장치 Download PDF

Info

Publication number
WO2018021734A1
WO2018021734A1 PCT/KR2017/007514 KR2017007514W WO2018021734A1 WO 2018021734 A1 WO2018021734 A1 WO 2018021734A1 KR 2017007514 W KR2017007514 W KR 2017007514W WO 2018021734 A1 WO2018021734 A1 WO 2018021734A1
Authority
WO
WIPO (PCT)
Prior art keywords
path
data
size
receiving device
transmitted
Prior art date
Application number
PCT/KR2017/007514
Other languages
English (en)
French (fr)
Inventor
황재현
강성룡
Original Assignee
삼성전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성전자 주식회사 filed Critical 삼성전자 주식회사
Priority to EP17834677.1A priority Critical patent/EP3471354A4/en
Priority to US16/316,464 priority patent/US11252608B2/en
Publication of WO2018021734A1 publication Critical patent/WO2018021734A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/10—Flow control between communication endpoints
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/24—Multipath
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/18—End to end
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
    • H04L47/263—Rate modification at the source after receiving feedback
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/30—Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/36—Flow control; Congestion control by determining packet size, e.g. maximum transfer unit [MTU]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/62—Queue scheduling characterised by scheduling criteria
    • H04L47/625—Queue scheduling characterised by scheduling criteria for service slots or service orders
    • H04L47/628—Queue scheduling characterised by scheduling criteria for service slots or service orders based on packet size, e.g. shortest packet first
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/12—Wireless traffic scheduling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]

Definitions

  • the present invention relates to a method and apparatus for transmitting data in multipath transmission.
  • a 5G communication system or a pre-5G communication system is called a system after a 4G network (Beyond 4G Network) or a system after an LTE system (Post LTE).
  • 5G communication systems are being considered for implementation in the ultra-high frequency (mmWave) band (eg, such as the 60 Gigabit (60 GHz) band).
  • FD-MIMO massive array multiple input / output
  • FD-MIMO massive array multiple input / output
  • FD-MIMO massive array multiple input / output
  • FD-MIMO massive array multiple input / output
  • FD-MIMO massive array multiple input / output
  • Array antenna, analog beam-forming, and large scale antenna techniques are discussed.
  • 5G communication systems have advanced small cells, advanced small cells, cloud radio access network (cloud RAN), ultra-dense network (ultra-dense network) , Device to Device communication (D2D), wireless backhaul, moving network, cooperative communication, Coordinated Multi-Points (CoMP), and interference cancellation
  • cloud RAN cloud radio access network
  • D2D Device to Device communication
  • D2D Device to Device communication
  • CoMP Coordinated Multi-Points
  • Hybrid FSK and QAM Modulation FQAM
  • SWSC Slide Window Superposition Coding
  • ACM Advanced Coding Modulation
  • FBMC Fan Bank Multi Carrier
  • NOMA non orthogonal multiple access
  • SCMA sparse code multiple access
  • IoT Internet of Things
  • IoE Internet of Everything
  • M2M machine to machine
  • MTC Machine Type Communication
  • IT intelligent Internet technology services can be provided that collect and analyze data generated from connected objects to create new value in human life.
  • IoT is a field of smart home, smart building, smart city, smart car or connected car, smart grid, health care, smart home appliances, advanced medical services, etc. through convergence and complex of existing information technology (IT) technology and various industries. It can be applied to.
  • TCP Transmission Control Protocol
  • devices such as smart phones, which are widely used in recent years, have multiple network interfaces such as 3G / 4G / 5G and Wi-Fi, but general TCP can transmit and receive data through only one interface at a time. Do.
  • MPTCP multi-path TCP
  • the MPTCP is an extension of the existing TCP.
  • the transmission device may generate a TCP subflow for every path and distribute data to each path.
  • the receiving device receiving the data may merge the distributed and transmitted data.
  • the transmission device limits the scheduling of data packets for any path, thereby transmitting data at an optimal transmission rate To provide.
  • a data transmission method of an apparatus for transmitting data through at least one of a first path and a second path may include data that can be transmitted to the first path during a reference time of the second path. Determining a size of the data, comparing the size of the checked data with a buffer size of the receiving device, determining a transmission mode based on the comparison result, and transmitting data to the receiving device according to the determined transmission mode. It may include a step.
  • the apparatus for transmitting data through at least one of the first path and the second path the transceiver for transmitting and receiving a signal and the reference path of the second path, the first path Determine the size of data that can be transmitted to the network, compare the size of the checked data with the buffer size of the receiving device, determine a transmission mode based on the comparison result, and transmit the data to the receiving device according to the determined transmission mode. It may include a control unit for controlling the transceiver to transmit.
  • the transmission device may limit data scheduling for an arbitrary path, thereby transmitting data at a transmission speed of at least a higher transmission speed.
  • FIG. 1 illustrates a structure of a transmitting device and a receiving device including a transport layer including MPTCP in general;
  • 2A and 2B illustrate a general buffer-blocking (or head-of-line blocking) problem
  • FIG. 3 is a diagram illustrating components of an apparatus for transmitting and receiving data according to an embodiment of the present invention
  • FIG. 4 is a diagram illustrating a method for a transmission device to determine a transmission state (or transmission mode) according to an embodiment of the present invention
  • FIG. 5 is a view for explaining a probing operation according to an embodiment of the present invention.
  • FIG. 6 is a diagram illustrating an embodiment in which the present invention is applied to an MPTCP (or multi-path transmission) proxy server.
  • MPTCP or multi-path transmission
  • FIG. 7A and 7B are views illustrating an effect according to an embodiment of the present invention.
  • FIG. 8 is a flowchart illustrating a method of an apparatus according to an embodiment of the present invention.
  • FIG. 9 is a block diagram illustrating components of an apparatus according to an exemplary embodiment.
  • the embodiments of the present invention will be described in detail, but the LTE system will be the main target, but the main subject of the present invention does not significantly depart from the scope of the present invention in other communication systems having a similar technical background and channel form. It can be applied in a slight modification in the scope, which will be possible in the judgment of those skilled in the art of the present invention.
  • each block of the flowchart illustrations and combinations of flowchart illustrations may be performed by computer program instructions. Since these computer program instructions may be mounted on a processor of a general purpose computer, special purpose computer, or other programmable data processing equipment, those instructions executed through the processor of the computer or other programmable data processing equipment may be described in flow chart block (s). It creates a means to perform the functions. These computer program instructions may be stored in a computer usable or computer readable memory that can be directed to a computer or other programmable data processing equipment to implement functionality in a particular manner, and thus the computer usable or computer readable memory. It is also possible for the instructions stored in to produce an article of manufacture containing instruction means for performing the functions described in the flowchart block (s).
  • Computer program instructions may also be mounted on a computer or other programmable data processing equipment, such that a series of operating steps may be performed on the computer or other programmable data processing equipment to create a computer-implemented process to create a computer or other programmable data. Instructions for performing the processing equipment may also provide steps for performing the functions described in the flowchart block (s).
  • each block may represent a portion of a module, segment, or code that includes one or more executable instructions for executing a specified logical function (s).
  • logical function e.g., a module, segment, or code that includes one or more executable instructions for executing a specified logical function (s).
  • the functions noted in the blocks may occur out of order.
  • the two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the corresponding function.
  • ' ⁇ part' used in the present embodiment refers to software or a hardware component such as an FPGA or an ASIC, and ' ⁇ part' performs certain roles.
  • ' ⁇ ' is not meant to be limited to software or hardware.
  • ' ⁇ Portion' may be configured to be in an addressable storage medium or may be configured to play one or more processors.
  • ' ⁇ ' means components such as software components, object-oriented software components, class components, and task components, and processes, functions, properties, procedures, and the like. Subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables.
  • components and 'parts' may be combined into a smaller number of components and 'parts' or further separated into additional components and 'parts'.
  • the components and ' ⁇ ' may be implemented to play one or more CPUs in the device or secure multimedia card.
  • each device transmitting / receiving data must support the MPTCP to be used.
  • the transmitting device and the receiving device may exchange information about whether MPTCP is available by including the MP_CAPABLE flag in the TCP header option field while performing three-way handshaking to start TCP communication. Can be. If the MPTCP is available in the transmitting device and the receiving device, the transmitting device and the receiving device exchange additionally available IP information and perform additional TCP subflow through separate three-way handshaking for each path. Can produce.
  • the MP_JOIN flag is included so that the transmitting device and the receiving device know that the connection is added to the existing session.
  • the number of TCP subflows generated may vary depending on the MPTCP path manager's policy. For example, in the “fullmesh” policy, as many subflows can be generated as the number of IPs of each end is multiplied with each other. For example, if two IPs are available on the terminal side and two IPs are available on the server side, a total of four subflows may be generated for each IP-pair.
  • FIG. 1 is a diagram illustrating a structure of a transmitting device and a receiving device including a transport layer 102 and 112 including MPTCPs 103 and 113 in general.
  • MPTCP (103, 113) can directly interact with the standard socket API by replacing the existing TCP location.
  • a plurality of TCP subflows are generated under the MPTCPs 103 and 113 to perform transmission according to the conventional TCP method.
  • data downloaded from the application layer 101 may be stored in the MPTCP send-queue 104 in order.
  • the multipath TCP scheduler 105 may distribute the send-queue of the TCP subflows 106-1 and 106-2. Each of the subflows 106-1 and 106-2 receiving the data acts as an independent TCP session.
  • the MPTCP 103 and the TCP subflows 106-1 and 106-2 use different kinds of sequence numbers. That is, at the MPTCP (103) level, data-sequence is used (representing the sequence of actual application data), and at the TCP subflow (106-1, 106-2) level, based on the data order distributed from the scheduler 105. Use a new subflow-sequence.
  • the data indicated by numbers 1 to 5 are accumulated in the MPTCP send-queue 104, and the MPTCP scheduler 105 has numbers 1 to 3 in the first subflow 106-1, the number 4, 5 was assigned to the second subflow 106-2.
  • the number 4 and 5 data may be converted to subflow sequence 1 and 2 again in the position of the second subflow 106-2 to perform transmission. Therefore, even though the data from the TCP subflows 116-1 and 116-2 of the receiver 110 arrives in order in terms of subflow-sequence, the data that the data-sequence preceded has not arrived in another path yet. If so, it can be moved to the out-of-order queue (113-1) of the MPTCP (113). The data moved to the ofo-queue 113-1 may be totally reassembled based on the data-sequence, transferred to the receive-queue 113-2, and then transmitted to the application layer 111.
  • the scheduling policy used as a default in the MPTCP reference code may use the fastest path first (Less-Delay First).
  • the scheduler transmits a data packet through an arbitrary path, and selects a subflow having the fastest round-trip delay (RTT), which is a time required to receive a feedback signal for the transmitted data packet. Can be assigned.
  • RTT round-trip delay
  • the scheduler can find the next fastest subflow.
  • a problem may occur in that a merge speed decreases when there are many speed differences for each transmission path. For example, when two paths exist between a transmitting device and a receiving device, if the RTT difference between the two paths is large, the data transmitted by the fast path is generally transmitted before MPOO's ofo-queue. Can be filled. Therefore, when the receive buffer becomes full, the fast path subflow can no longer transmit data.
  • FIGS. 2A and 2B illustrate general buffer-blocking (or head-of-line blocking) problems.
  • FIG. 2A illustrates a case where the speed difference between the two paths is not large.
  • the reception buffer 200 may still have free space before data transmitted through the slow path 220 arrives at the reception buffer 200. Therefore, the speed decrease may not occur on the fast path 210.
  • the data transmitted to the slow path 220 may be fast before arrival.
  • the receive buffer 200 may become full with data sent to the path 210. Therefore, after the reception buffer 200 is full, the transmission of data through the fast path 210 is limited.
  • a method of retransmitting data that has not yet arrived (data 1 of FIG. 2B) to the fast path 210 when the reception buffer 200 is full with out-of-order data may be used.
  • Opportunistic Retransmission If the reception buffer 200 is empty through retransmission, transmission can be resumed from the next number (data 6 of FIG. 2B) of the transmitted data packet.
  • the function of reducing the TCP congestion window value of the slow path 220 by half may be used together (Penalization). Nevertheless, when both paths 210 and 220 are used at the same time, the transmission of data in the fast path 210 may be frequently restricted.
  • the reception buffer of the terminal can be easily filled with only a few times the RTT difference. Therefore, deterioration of merging performance of the wifi path and other paths may occur frequently. If the receive buffer is very large, the problem of performance degradation may not occur. However, in general, since there is a limitation in the memory size of the terminal, it may be difficult to increase the size of the TCP reception buffer so as not to be affected by the difference in speed for each path.
  • the scheduler of the device may limit packet scheduling to the slow path and perform scheduling again when the situation of the slow path is improved later. Therefore, even if one path becomes very crowded or slows, buffer-blocking may reduce the speed of the other path.
  • FIG. 3 is a diagram illustrating the components of an apparatus for transmitting and receiving data according to an embodiment of the present invention.
  • the MPTCP sender 300 shown in FIG. 3 may include a path monitor 310 for collecting information necessary for scheduling and a scheduler 320 designed to avoid buffer-blocking.
  • the path monitor 310 may collect information necessary for detecting a buffer-blocking situation. For example, the buffer status information of the receiver and the transmission related information (for example, RTT, congestion window, etc.) for the subflow of the transmitter can be checked. In the case of TCP, the information may be obtained through feedback such as ACK, or may be obtained through another measurement network element 301.
  • the path monitor unit 310 may receive information about a congestion situation or downlink transmission rate of the network from the base station 302, the DPI 303, or the analytics equipment 304.
  • the scheduler 320 may use the received information when scheduling.
  • the buffer blocking detector 321 of the scheduler 320 may determine whether the reception buffer is blocked based on the information obtained through the path monitor 310 (Buffer). -Blocking Detection).
  • the scheduler 320 may stop scheduling to a slow subflow. However, it is necessary to keep the transmission related information such as RTT to the latest value even for the subflow which has limited scheduling in order to change the path condition (for example, the transmission rate) in the future.
  • the path probing management unit 322 of the scheduler 320 may manage to permit packet scheduling for path probing. Therefore, it is possible to directly retransmit probing data scheduled in a slow subflow to a fast subflow so that buffer-blocking does not occur.
  • the scheduler 320 of the MPTCP sender determines whether the reception buffer is blocked.
  • the scheduler 320 may perform the following operations when scheduling data down from an application layer into each subflow.
  • the scheduler 320, the path display unit 321 is available for transmission packet number per RTT in the fast path (TxData fast), the fast path RTT (Round-Trip Time) (Delay fast), the slow path RTT (Round of Trip Time ( Delay slow ), Fast Segment Maximum Segment Size ( MSS fast ), Number of Packets Transmitting on Fast Path ( in_ flight fast ), Number of Packets Transmitting on Slow Path ( in_flight slow ), and The reception buffer size rwnd may be obtained.
  • the path monitor unit 321 may update the information each time the data coming down from the application layer is scheduled in each subflow.
  • the buffer blocking detector 321 of the scheduler 320 may determine whether the reception buffer is blocked based on the information obtained through the path monitor 310 (Buffer). -Blocking Detection).
  • the buffer blocking detection unit 321 may calculate a data size rcv _ queued fast that may be transmitted in a fast path in the delay slow period according to Equation 1.
  • TxData fast of Equation 1 is the number of packets that can be transmitted during the reference time (RTT) in the fast path
  • Delay slow is the reference time (RTT) for the slow path
  • MSS fast may be the maximum segment size (MSS) for the fast path.
  • the MSS fast may be regarded as the size of one transport packet for the fast path.
  • the TxData fast is a value that can vary depending on the congestion conditions of the fast path and the slow path. For example, when applied to TCP, the TxData fast may be applied to min ( in_ flight fast , cwnd fast / 2), etc. ( cwnd fast is a fast path congestion window).
  • the scheduler 320 may determine the transmission state (or transmission mode) by comparing the TxData fast value with the reception buffer size rwnd. For example, the scheduler 320 may determine whether to limit scheduling over a slow path.
  • the scheduler 320 may determine a scheduling state as a normal state to transmit data using both a fast path and a slow path.
  • the scheduler 320 may determine a pruning state as a state in which scheduling of the slow path is restricted.
  • the scheduler 320 may use an existing scheduling algorithm in a normal state. For example, when the value of TxData fast is smaller than the reception buffer size rwnd, the transmission of the fast path may not be restricted even if the slow path is used, so that the scheduler 320 maintains a normal state or the Can transition to normal state.
  • the scheduler 320 transitions to the pruning state, it can limit the scheduling to a slow path. For example, If the value of TxData fast is larger than the receive buffer size rwnd, a blockage may occur for the receive buffer. Accordingly, the scheduler 320 may transition to the pruning state and may not perform scheduling for data transmission through the slow path except for data packet transmission for performing probing.
  • FIG. 5 is a view for explaining a probing operation according to an embodiment of the present invention.
  • the scheduler 320 may perform probing in a slow path. For example, the scheduler 320 may continuously measure the RTT of the slow path and allow scheduling on the slow path once every time in_ flight slow becomes 0 (or every RTT). If scheduling is allowed in the slow path, the in_flight slow is equal to or greater than 0, and the scheduler 320 may immediately retransmit the packet transmitted in the slow path. Specifically, since the reception buffer blockage may occur due to the scheduled packet transmission, the scheduler 320 may prevent the reception buffer blockage by retransmitting the same packet as the packet scheduled in the slow path in the fast path.
  • the scheduler 320 moves packet 3 501 to the slow path 510. Can be sent by scheduling.
  • the scheduler 320 may retransmit the packet 501 three times through the fast path 520 to prevent the reception buffer from clogging. From the fourth packet thereafter, since the in_ flight slow is greater than or equal to zero, packet scheduling may be performed only through the fast path 520 again.
  • the receiving device may discard one packet among the duplicated received packets.
  • the scheduler 320 may determine that the transmission speed of the slow path 510 is still low through the probing operation to the slow path 510.
  • a feedback for example, ACK
  • the device may measure the RTT of the slow path 510.
  • the scheduler 320 may determine a transmission state according to Equation 1 at the next scheduling execution.
  • the scheduler 320 may determine to maintain the pruning state or change to the normal state.
  • TCP can calculate the RTT smoothed RTT according to Equation 2 whenever the RTT sample value (RTT) is obtained.
  • the new measured RTT sample value can be updated by giving a low specific gravity of 1/8.
  • the smoothed_RTT of a slow path in the pruning state when updating the smoothed_RTT of a slow path in the pruning state, it may be necessary to use only a very small number of probing packets. Therefore, in order to quickly reflect the currently changing path information, it may be desirable to give a higher weight to the sample value than the representative value. Lower than 7/8 when updating the smoothed_RTT value by the Probing packet. You can use the value. (For example, You can use 1/8 as the value.)
  • a value of 1/8 or 7/8 is just one embodiment.
  • the value can be a real number less than 0 and less than 1.
  • the above-described embodiment of the present invention has been described assuming that one path is fast and the other path is slow with respect to two paths. According to another embodiment of the present invention, the above-described method may be applied to three or more multipath transmissions having different speeds.
  • rcv_queuedr fast for a specific path r ( 1 ⁇ r ⁇ N ).
  • the scheduler 300 may determine whether a speed decrease may occur due to buffer-blocking on paths 1 to r-1 by using the path r.
  • the scheduler 300 is rcv _ queuedr fast Can be calculated as in Equation 3.
  • the scheduler 300 is rcv _ queuedr fast If r is greater than rwnd, then path r can be defined as a slow path.
  • the scheduler 300 may perform an operation in the pruning state as described above with respect to the path determined as the slow path.
  • FIG. 6 is a diagram illustrating an embodiment when the present invention is applied to an MPTCP (or multi-path transmission) proxy server.
  • the terminal 600 may first connect to the MPTCP Proxy server through multiple connections, and establish a connection using the TCP with the final destination to which the terminal intends to connect again in the MPTCP Proxy server 610.
  • the MPTCP Proxy server 610 may perform a relay between the connection with the terminal 600 and the connection with the final destination. (If the final destination server supports multipath transmission, direct multipath transmission between the terminal and the final destination server is possible without a proxy. In this case, the embodiment of the present invention can be applied to the final destination server.)
  • MPTCP Proxy server 610 May be on the mobile network or immediately after the mobile network (eg, connected to the SGi), or on the Internet.
  • the MPTCP Proxy server 610 may receive more accurate information about the network state from the base station or another measurement element, and may use it in packet scheduling. Otherwise, the MPTCP Proxy server 610 may perform packet scheduling by using information such as RTT and reception buffer size measured when transmitting data in the existing TCP.
  • Figure 7a and 7b is a diagram illustrating the effect according to an embodiment of the present invention.
  • FIGS. 7A and 7B show an example in which a proxy server is provided between the client and the server, and the client and the proxy server support MPTCP and the server does not.
  • the client may communicate with the server via the proxy, and the proxy may establish an MPTCP connection with the client, establish a general TCP connection with the server, and perform a relay between the client and the server.
  • 7A is a diagram illustrating a result of performing scheduling by a general method.
  • 7B is a diagram illustrating a result when the proxy server performs a scheduling operation according to an embodiment of the present invention.
  • the Path1-only performance is 149Mbps when the Path1 delay is 30ms
  • the Path2-only performance is 497Mbps when the Path2 delay is 6ms.
  • FIG. 8 is a flowchart illustrating a method of an apparatus according to an exemplary embodiment.
  • the device may check the size of data that can be transmitted to the first path during the reference time of the second path.
  • the second path may be a path having a lower transmission speed than the first path
  • the first path may be a path having a higher transmission speed than the second path.
  • the apparatus may check the size of data that can be transmitted to the first path during the reference time of the second path using Equation 1 described above.
  • the device may determine whether the size of the confirmed data exceeds the buffer size of the receiving device. For example, when the device receives an ACK signal for a data packet transmitted to the receiving device, the device may check the buffer size of the receiving device based on the information included in the ACK signal. Therefore, the device may determine whether the size of the checked data exceeds the buffer size of the receiving device.
  • the device may determine the transmission mode as the second mode.
  • the device performs scheduling to transmit data to the receiving device through the first path having a faster data transmission speed than the second path, and restricts scheduling of data to the second path. can do.
  • the second mode is to schedule the device to transmit through the second path any packets that are transmitted to the first path at predetermined intervals, while scheduling the device to transmit data packets along the first path. May be a mode.
  • the device may transmit the arbitrary packet via the first path and the second path while scheduling data in the second mode. For example, the device may transmit any packet over the first path and the second path, once per RTT of the second path.
  • the device may determine the size of data that may be transmitted to the first path during the reference time of the second path according to the transmission of the arbitrary packet.
  • the apparatus which has confirmed the size of data that can be transmitted to the first path during the reference time of the second path by transmitting the arbitrary packet, may proceed to step S805 again.
  • step S805 if it is determined in step S805 that the size of the checked data does not exceed the buffer size of the receiving device, the device may proceed to step S830 to determine the transmission mode in the first mode.
  • the device may schedule to transmit data to the receiving device through the first path and the second path.
  • the device may perform scheduling to transmit data by a general MPCTP scheme.
  • FIG. 9 is a block diagram illustrating the components of a transmission apparatus 900 according to an embodiment of the present invention.
  • the transmission device 900 may include a transceiver 910 and a controller 920.
  • the transceiver 910 is a component for transmitting and receiving signals.
  • controller 920 may control the overall transmission device 900.
  • the controller 920 may check the size of data that can be transmitted to the first path during the reference time of the second path. The size of the checked data and the buffer size of the receiver may be compared. The controller 920 may determine a transmission mode based on the comparison result, and transmit data to the receiving device according to the determined transmission mode.
  • the controller 920 may determine a first mode for scheduling to transmit data to the receiving device through the first path and the second path. have.
  • the controller 920 schedules the data to be transmitted to the receiving device through the first path having a faster data transmission rate than the second path.
  • the second mode may be configured to limit scheduling of data to the second path.
  • Restricting scheduling of data to the second path is such that scheduling of data packets to be transmitted on the first path transmits any packets to the first path at predetermined intervals via the second path. May be scheduled to.
  • the controller 920 transmits an arbitrary packet through the first path and the second path while operating in the second mode, and during the reference time of the second path according to the transmission of the arbitrary packet.
  • the size of data that can be transmitted through the first path can be checked.
  • the controller 920 may determine whether to transmit data to the second path based on the confirmation result.
  • the controller 920 determines that the first A first mode for transmitting data to the receiving device through a path and the second path may be switched.
  • the controller 920 may maintain the second mode.
  • the comparing feature may compare the size of the data and the buffer size of the receiver according to Equation 1 as described above.
  • the reference time may be a round-trip time (RTT) until a data packet is transmitted through an arbitrary path and a feedback signal for the transmitted data packet is received from the receiving apparatus.
  • RTT round-trip time
  • the transmission apparatus 900 described above even when performing multipath transmission in an environment where speed differences between paths are large, at least a fast path transmission speed can be guaranteed regardless of a reception buffer size.
  • the scheduling method of the apparatus may be coded in software and stored in a non-transitory readable medium.
  • Such non-transitory readable media can be mounted and used in a variety of devices.
  • the non-transitory readable medium refers to a medium that stores data semi-permanently and is readable by a device, not a medium storing data for a short time such as a register, a cache, a memory, and the like. Specifically, it may be a CD, a DVD, a hard disk, a Blu-ray disk, a USB, a memory card, a ROM, or the like.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

본 개시는 4G 시스템 이후 보다 높은 데이터 전송률을 지원하기 위한 5G 통신 시스템을 IoT 기술과 융합하는 통신 기법 및 그 시스템에 관한 것이다. 본 개시는 5G 통신 기술 및 IoT 관련 기술을 기반으로 지능형 서비스 (예를 들어, 스마트 홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 헬스 케어, 디지털 교육, 소매업, 보안 및 안전 관련 서비스 등)에 적용될 수 있다. 제1 경로 및 제2 경로 중 적어도 하나를 통해 데이터를 전송하는 장치 및 이의 방법이 개시된다. 본 발명의 일 실시 예에 따른 장치의 방법은, 제2 경로의 기준 시간 동안, 제1 경로로 전송할 수 있는 데이터의 크기를 확인하는 단계, 확인된 데이터의 크기 및 수신 장치의 버퍼 크기를 비교하는 단계 및 비교 결과에 기반하여 전송 모드를 결정하고, 결정된 전송 모드에 따라 수신 장치로 데이터를 전송하는 단계를 포함할 수 있다.

Description

무선 통신 시스템에서 데이터의 전송 방법 및 장치
본 발명은 다중 경로 전송에 있어서, 데이터를 전송하는 방법 및 장치에 관한 것이다.
4G 통신 시스템 상용화 이후 증가 추세에 있는 무선 데이터 트래픽 수요를 충족시키기 위해, 개선된 5G 통신 시스템 또는 pre-5G 통신 시스템을 개발하기 위한 노력이 이루어지고 있다. 이러한 이유로, 5G 통신 시스템 또는 pre-5G 통신 시스템은 4G 네트워크 이후 (Beyond 4G Network) 통신 시스템 또는 LTE 시스템 이후 (Post LTE) 이후의 시스템이라 불리어지고 있다. 높은 데이터 전송률을 달성하기 위해, 5G 통신 시스템은 초고주파(mmWave) 대역 (예를 들어, 60기가(60GHz) 대역과 같은)에서의 구현이 고려되고 있다. 초고주파 대역에서의 전파의 경로손실 완화 및 전파의 전달 거리를 증가시키기 위해, 5G 통신 시스템에서는 빔포밍(beamforming), 거대 배열 다중 입출력(massive MIMO), 전차원 다중입출력(Full Dimensional MIMO: FD-MIMO), 어레이 안테나(array antenna), 아날로그 빔형성(analog beam-forming), 및 대규모 안테나 (large scale antenna) 기술들이 논의되고 있다. 또한 시스템의 네트워크 개선을 위해, 5G 통신 시스템에서는 진화된 소형 셀, 개선된 소형 셀 (advanced small cell), 클라우드 무선 액세스 네트워크 (cloud radio access network: cloud RAN), 초고밀도 네트워크 (ultra-dense network), 기기 간 통신 (Device to Device communication: D2D), 무선 백홀 (wireless backhaul), 이동 네트워크 (moving network), 협력 통신 (cooperative communication), CoMP (Coordinated Multi-Points), 및 수신 간섭제거 (interference cancellation) 등의 기술 개발이 이루어지고 있다. 이 밖에도, 5G 시스템에서는 진보된 코딩 변조(Advanced Coding Modulation: ACM) 방식인 FQAM (Hybrid FSK and QAM Modulation) 및 SWSC (Sliding Window Superposition Coding)과, 진보된 접속 기술인 FBMC(Filter Bank Multi Carrier), NOMA(non orthogonal multiple access), 및SCMA(sparse code multiple access) 등이 개발되고 있다.
한편, 인터넷은 인간이 정보를 생성하고 소비하는 인간 중심의 연결 망에서, 사물 등 분산된 구성 요소들 간에 정보를 주고 받아 처리하는 IoT(Internet of Things, 사물인터넷) 망으로 진화하고 있다. 클라우드 서버 등과의 연결을 통한 빅데이터(Big data) 처리 기술 등이 IoT 기술에 결합된 IoE (Internet of Everything) 기술도 대두되고 있다. IoT를 구현하기 위해서, 센싱 기술, 유무선 통신 및 네트워크 인프라, 서비스 인터페이스 기술, 및 보안 기술과 같은 기술 요소 들이 요구되어, 최근에는 사물간의 연결을 위한 센서 네트워크(sensor network), 사물 통신(Machine to Machine, M2M), MTC(Machine Type Communication)등의 기술이 연구되고 있다. IoT 환경에서는 연결된 사물들에서 생성된 데이터를 수집, 분석하여 인간의 삶에 새로운 가치를 창출하는 지능형 IT(Internet Technology) 서비스가 제공될 수 있다. IoT는 기존의 IT(information technology)기술과 다양한 산업 간의 융합 및 복합을 통하여 스마트홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 스마트 그리드, 헬스 케어, 스마트 가전, 첨단의료서비스 등의 분야에 응용될 수 있다.
이에, 5G 통신 시스템을 IoT 망에 적용하기 위한 다양한 시도들이 이루어지고 있다. 예를 들어, 센서 네트워크(sensor network), 사물 통신(Machine to Machine, M2M), MTC(Machine Type Communication)등의 기술이 5G 통신 기술인 빔 포밍, MIMO, 및 어레이 안테나 등의 기법에 의해 구현되고 있는 것이다. 앞서 설명한 빅데이터 처리 기술로써 클라우드 무선 액세스 네트워크(cloud RAN)가 적용되는 것도 5G 기술과 IoT 기술 융합의 일 예라고 할 수 있을 것이다.
한편, 인터넷 환경에서 종단간 신뢰적 커뮤니케이션은 전통적으로 TCP (Transmission Control Protocol)를 사용하여 이루어져왔다. 그러나 최근 들어 종단간 하나 이상의 인터넷 경로를 활용하는 것이 가능해짐에 따라, 기존의 단일 경로만을 활용하는 TCP의 한계점이 지적되었다. 예를 들어, 최근 널리 보급되어 사용되고 있는 스마트 폰과 같은 장치는 3G/4G/5G 및 와이파이(WiFi) 등 복수 개의 네트워크 인터페이스를 가지고 있으나, 일반적인 TCP는 한 번에 하나의 인터페이스만을 통한 데이터 송수신이 가능하다.
상기와 같은 한계를 극복하고, 성능 향상을 위해, 단말이 가지는 복수 개의 인터페이스, 또는 종단간 다중 경로를 동시에 활용하여 데이터를 전송할 수 있는 기술들이 제안되고 있다. 예를 들면, 다중 경로 TCP (multi-path TCP, MPTCP)가 있다. 상기 MPTCP는 기존의 TCP를 확장한 것으로, 종단간에 하나 이상의 경로가 존재할 경우, 전송 장치는 모든 경로마다 TCP 서브플로우 (subflow)를 생성하여 각 경로로 데이터를 분배하여 전송할 수 있다. 상기 데이터를 수신한 수신 장치는 상기 분배하여 전송된 데이터를 병합할 수 있다.
한편, 상기와 같은 복수 개의 경로를 통해 데이터를 송수신하는 경우, 상기 복수개의 경로 간의 데이터 전송 속도가 상이할 수 있으며, 전송 속도 차이가 클 경우 수신 장치의 제약으로 인해 복수 경로를 사용한 병합 성능이 단일 경로를 사용할 때보다 저하될 가능성이 있다.
상기와 같은 문제점을 해결하기 위해, 본 발명에서는 경로 별 전송 속도 차이가 발생하는 경우에도, 전송 장치가 임의의 경로에 대해 데이터 패킷의 스케줄링을 제한함으로써, 최적의 전송 속도로 데이터를 전송하기 위한 방법을 제공한다.
본 발명의 일 실시 예에 따르면, 제1 경로 및 제2 경로 중 적어도 하나를 통해 데이터를 전송하는 장치의 데이터 전송 방법은, 상기 제2 경로의 기준 시간 동안, 상기 제1 경로로 전송할 수 있는 데이터의 크기를 확인하는 단계, 상기 확인된 데이터의 크기 및 수신 장치의 버퍼 크기를 비교하는 단계 및 상기 비교 결과에 기반하여 전송 모드를 결정하고, 상기 결정된 전송 모드에 따라 상기 수신 장치로 데이터를 전송하는 단계를 포함할 수 있다.
한편, 본 발명의 다른 실시 예에 따르면, 제1 경로 및 제2 경로 중 적어도 하나를 통해 데이터를 전송하는 장치는, 신호를 송수신하는 송수신부 및 상기 제2 경로의 기준 시간 동안, 상기 제1 경로로 전송할 수 있는 데이터의 크기를 확인하고, 상기 확인된 데이터의 크기 및 수신 장치의 버퍼 크기를 비교하며 상기 비교 결과에 기반하여 전송 모드를 결정하고, 상기 결정된 전송 모드에 따라 상기 수신 장치로 데이터를 전송하도록 상기 송수신부를 제어하는 제어부를 포함할 수 있다.
본 발명의 실시 예에 따르면, 경로 별 전송 속도 차이가 발생하는 경우에도, 전송 장치가 임의의 경로에 대해 데이터 패킷의 스케줄링을 제한함으로써, 최소한 전송 속도가 더 빠른 경로의 전송 속도로 데이터를 전송할 수 있다.
도 1은 일반적으로, MPTCP가 포함된 전송 계층 (Transport Layer)을 포함하는 전송 장치 및 수신 장치의 구조를 도시한 도면,
도 2a 및 도 2b는 일반적인 buffer-blocking (또는 head-of-line blocking) 문제를 도시한 도면,
도 3은 본 발명의 일 실시 예에 따른, 데이터를 송수신하는 장치의 구성요소를 도시한 도면,
도 4는 본 발명의 일 실시 예에 따른, 전송 장치가 전송 상태(또는 전송 모드)를 결정하는 방법을 나타내는 도면,
도 5는 본 발명의 일 실시 예에 따라, Probing 동작을 설명하기 위한 도면,
도 6은 MPTCP (또는 다중 경로 전송이 가능한) 프록시 서버(Proxy server)에 본 발명을 적용했을 경우의 실시 예를 나타낸 도면,
도 7a 및 도 7b는 본 발명의 일 실시 예에 따른 효과를 설명하는 도면,
도 8은 본 발명의 일 실시 예에 따른, 장치의 방법을 나타내는 흐름도, 그리고,
도 9는 본 발명의 일 실시 예에 따른, 장치의 구성요소를 도시한 블록도 이다.
이하, 첨부된 도면을 참조하여 본 발명의 바람직한 실시 예들을 상세히 설명한다. 이때, 첨부된 도면에서 동일한 구성 요소는 가능한 동일한 부호로 나타내고 있음에 유의해야 한다. 또한, 본 발명의 요지를 흐리게 할 수 있는 공지 기능 및 구성에 대한 상세한 설명은 생략할 것이다.
또한, 본 발명의 실시 예들을 구체적으로 설명함에서, LTE 시스템을 주된 대상으로 할 것이지만, 본 발명의 주요한 요지는 유사한 기술적 배경 및 채널형태를 가지는 여타의 통신 시스템에도 본 발명의 범위를 크게 벗어나지 아니하는 범위에서 약간의 변형으로 적용 가능하며, 이는 본 발명의 기술분야에서 숙련된 기술적 지식을 가진 자의 판단으로 가능할 것이다.
본 명세서에서 실시 예를 설명함에서 본 발명이 속하는 기술 분야에 익히 알려졌고 본 발명과 직접적으로 관련이 없는 기술 내용에 대해서는 설명을 생략한다. 이는 불필요한 설명을 생략함으로써 본 발명의 요지를 흐리지 않고 더욱 명확히 전달하기 위함이다.
마찬가지 이유로 첨부 도면에서 일부 구성요소는 과장되거나 생략되거나 개략적으로 도시되었다. 또한, 각 구성요소의 크기는 실제 크기를 전적으로 반영하는 것이 아니다. 각 도면에서 동일한 또는 대응하는 구성요소에는 동일한 참조 번호를 부여하였다.
본 발명의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시 예들을 참조하면 명확해질 것이다. 그러나 본 발명은 이하에서 개시되는 실시 예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시 예들은 본 발명의 개시가 완전하도록 하고, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 발명은 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.
이때, 처리 흐름도 도면들의 각 블록과 흐름도 도면들의 조합들은 컴퓨터 프로그램 인스트럭션들에 의해 수행될 수 있음을 이해할 수 있을 것이다. 이들 컴퓨터 프로그램 인스트럭션들은 범용 컴퓨터, 특수용 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서에 탑재될 수 있으므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서를 통해 수행되는 그 인스트럭션들이 흐름도 블록(들)에서 설명된 기능들을 수행하는 수단을 생성하게 된다. 이들 컴퓨터 프로그램 인스트럭션들은 특정 방식으로 기능을 구현하기 위해 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 지향할 수 있는 컴퓨터 이용 가능 또는 컴퓨터 판독 가능 메모리에 저장되는 것도 가능하므로, 그 컴퓨터 이용가능 또는 컴퓨터 판독 가능 메모리에 저장된 인스트럭션들은 흐름도 블록(들)에서 설명된 기능을 수행하는 인스트럭션 수단을 내포하는 제조 품목을 생산하는 것도 가능하다. 컴퓨터 프로그램 인스트럭션들은 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에 탑재되는 것도 가능하므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에서 일련의 동작 단계들이 수행되어 컴퓨터로 실행되는 프로세스를 생성해서 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 수행하는 인스트럭션들은 흐름도 블록(들)에서 설명된 기능들을 실행하기 위한 단계들을 제공하는 것도 가능하다.
또한, 각 블록은 특정된 논리적 기능(들)을 실행하기 위한 하나 이상의 실행 가능한 인스트럭션들을 포함하는 모듈, 세그먼트 또는 코드의 일부를 나타낼 수 있다. 또, 몇 가지 대체 실행 예들에서는 블록들에서 언급된 기능들이 순서를 벗어나서 발생하는 것도 가능함을 주목해야 한다. 예컨대, 잇달아 도시되어 있는 두 개의 블록들은 사실 실질적으로 동시에 수행되는 것도 가능하고 또는 그 블록들이 때때로 해당하는 기능에 따라 역순으로 수행되는 것도 가능하다.
이때, 본 실시 예에서 사용되는 '~부'라는 용어는 소프트웨어 또는 FPGA 또는 ASIC과 같은 하드웨어 구성요소를 의미하며, '~부'는 어떤 역할들을 수행한다. 그렇지만 '~부'는 소프트웨어 또는 하드웨어에 한정되는 의미는 아니다. '~부'는 어드레싱할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 재생시키도록 구성될 수도 있다. 따라서, 일 예로서 '~부'는 소프트웨어 구성요소들, 객체지향 소프트웨어 구성요소들, 클래스 구성요소들 및 태스크 구성요소들과 같은 구성요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들, 및 변수들을 포함한다. 구성요소들과 '~부'들 안에서 제공되는 기능은 더 작은 수의 구성요소들 및 '~부'들로 결합하거나 추가적인 구성요소들과 '~부'들로 더 분리될 수 있다. 그뿐만 아니라, 구성요소들 및 '~부'들은 디바이스 또는 보안 멀티미디어카드 내의 하나 또는 그 이상의 CPU들을 재생시키도록 구현될 수도 있다.
일반적으로, 다중 경로 TCP (multi-path TCP, MPTCP)에서, 데이터를 송수신하는 각각의 장치가 모두 상기 MPTCP를 지원을 해야 사용이 가능하다. 따라서, 송신 장치 및 수신 장치는 TCP 통신을 시작하기 위해 three-way handshaking을 수행하면서 TCP 헤더 옵션 필드(TCP header option field)에 MP_CAPABLE 플래그(flag)를 포함시켜 MPTCP가 사용 가능한지에 대한 정보를 교환할 수 있다. 만약 송신 장치 및 수신 장치에서 상기 MPTCP가 사용 가능하다면 상기 송신 장치 및 수신 장치는 추가로 사용 가능한 IP 정보를 서로 교환하고, 각 경로 별로 별도의 three-way handshaking을 통해 추가 TCP 서브 플로우(subflow)를 생성할 수 있따.
이때, 상기 three-way handshaking를 수행하면서, MP_JOIN 플래그를 포함시켜 송신 장치 및 수신 장치는 기존 세션에 추가되는 연결임을 알 수 있게 한다. TCP subflow의 생성 개수는 MPTCP 경로 매니저 (path manager)의 정책에 따라 다를 수 있다. 예를 들면, “fullmesh” 정책에서는 각 종단의 IP 개수를 서로 곱한 수만큼의 subflow가 생성될 수 있다. 예를 들어 단말 측에 IP 2개, 서버 측에 IP 2개가 사용 가능하다면 subflow는 각 IP-pair 만큼, 총 4개의 subflow가 생성될 수 있다.
도 1은 일반적으로, MPTCP(103, 113)가 포함된 전송 계층 (Transport Layer)(102, 112)을 포함하는 전송 장치 및 수신 장치의 구조를 도시한 도면이다.
도 1에 도시된 바와 같이, MPTCP(103, 113)가 기존의 TCP 위치를 대체하여 표준 소켓 API와 직접 연동할 수 있다. MPTCP(103, 113) 아래에는 다수의 TCP subflow들이 생성되어 기존의 TCP 방식대로 전송을 수행할 수 있다.
도 1의 전송 장치의 MPTCP 송신자(sender)(100)에서 살펴보면, 응용 계층 (Application Layer)(101)에서 내려온 데이터는 MPTCP send-queue(104)에 순서대로 저장될 수 있다. 이를 Multipath TCP Scheduler(105)가 TCP subflow(106-1, 106-2)의 send-queue로 분배하는 역할을 할 수 있다. 그리고 데이터를 분배받은 각각의 subflow들(106-1, 106-2)은 마치 독립적인 TCP 세션처럼 동작하게 된다.
이때, 경로마다 대역폭, 지연시간 등이 다르기 때문에 TCP subflow(106-1, 106-2) 들로부터 수신된 데이터의 순서를 맞출 필요가 있다. 따라서, MPTCP(103)와 TCP subflow(106-1, 106-2)는 서로 다른 종류의 시퀀스(sequence) 번호를 사용한다. 즉, MPTCP(103) 수준에서는 data-sequence를 사용하며 (실제 응용 데이터의 순서를 나타냄), TCP subflow(106-1, 106-2) 수준에서는 스케줄러(105)에서 분배되어 내려온 데이터 순서를 기반으로 새로 subflow-sequence를 붙여서 사용한다.
예를 들어, 도 1에서 번호 1부터 5로 표시된 데이터가 MPTCP send-queue(104)에 쌓여 있고, MPTCP 스케줄러(105)가 번호 1 내지 3은 첫 번째 subflow(106-1)에, 번호 4, 5는 두 번째 subflow(106-2)에 할당하였다.
이때 두 번째 subflow(106-2)의 입장에서 번호 4, 5 데이터는 다시 subflow-sequence 1, 2번으로 전환되어 전송을 수행할 수 있다. 따라서 수신 측(110)의 TCP subflow(116-1, 116-2)에서 올라온 데이터는 subflow-sequence 측면에서 순서에 맞게 도착했을지라도, 아직 data-sequence가 앞선 데이터가 다른 경로에서 도착을 안 한 상황이라면, MPTCP(113)의 ofo-queue (out-of-order queue)(113-1)로 이동될 수 있다. 그리고 상기 ofo-queue (113-1) 로 이동된 데이터는 data-sequence를 기반으로 전체적으로 재조립되어 receive-queue(113-2)에 옮겨진 뒤 응용 계층(111)으로 전송될 수 있다.
전술한 바와 같이, 다중 경로 전송에서는 전송 순서와 도착 순서가 달라지는 상황이 빈번하게 발생할 수 있기 때문에, 어느 데이터를 어느 경로로 보낼 것인가를 결정하는 패킷 스케줄러의 역할이 매우 중요할 수 있다.
일반적으로 MPTCP 참조 코드에서 디폴트로 사용되는 스케줄링 정책은 가장 빠른 경로를 우선적으로 사용하는 방안이 사용될 수 있다(Less-Delay First). 상기 방안에 따르면, 스케줄러는 임의의 경로로 데이터 패킷을 전송하고, 전송된 데이터 패킷에 대한 피드백 신호가 수신될 때까지 소요되는 시간인, RTT (Round-Trip Delay)가 가장 빠른 subflow를 선택하여 패킷을 할당할 수 있다. 그리고 상기 가장 빠른 subflow의 TCP 혼잡 윈도우 (congestion window)가 가득 차서 더는 보낼 수 없을 때, 상기 스케줄러는 그 다음으로 빠른 subflow를 찾을 수 있다.
전술한 방법에 의해, 다중 경로 전송이 수행되는 경우, 전송 경로 별로 속도 차이가 많이 날 때는, 병합 속도가 저하되는 문제가 발생할 수 있다. 예를 들어, 전송 장치 및 수신 장치 사이에 두 경로가 존재할 때, 두 경로의 RTT 차이가 크게 벌어진다면, 일반적으로 느린 경로로 오는 데이터가 도착하기 전에 빠른 경로로 전송되는 데이터가 MPTCP의 ofo-queue를 채울 수 있다. 따라서, 수신 버퍼가 가득 차게 되면 빠른 경로의 subflow는 더 이상의 데이터 전송을 할 수 없게 된다.
구체적으로, 도 2a 및 도 2b는 일반적인 buffer-blocking (또는 head-of-line blocking) 문제를 도시한 도면이다. 먼저 도 2a는 두 경로의 속도 차이가 크지 않은 경우를 도시한 도면이다. 상기 도 2a에 따르면, 수신 버퍼(200)는 느린 경로(220)로 전송되는 데이터가 상기 수신 버퍼(200)에 도착하기 전에도 아직 여유 공간이 있을 수 있다. 따라서 빠른 경로(210) 상에 속도 저하가 발생하지 않을 수 있다.
반면, 도 2b에 도시된 바와 같이, 빠른 경로(210) 및 느린 경로(220) 간의 속도 차이가 커지는 경우, 느린 경로(220)로 전송된 데이터(도 2b의 1번 데이터)가 도착하기 전에 빠른 경로(210)로 보내진 데이터로 수신 버퍼(200)가 가득 차게 될 수 있다. 따라서, 상기 수신 버퍼(200)가 가득 찬 이후에는, 빠른 경로(210)로 데이터를 전송하는 것이 제한된다.
상술한 문제점을 해결하기 위해, 수신 버퍼(200) 가 out-of-order 데이터로 가득 찼을 때 아직 도착하지 않은 데이터(도 2b의 1번 데이터)를 빠른 경로(210)로 재전송하는 방법이 사용될 수 있다(Opportunistic Retransmission). 재전송을 통해 수신 버퍼(200)가 비워지면, 전송된 데이터 패킷의 다음 번호(도 2b의 6번 데이터)부터 전송을 재개할 수 있다. 그러나 상술한 방법으로, 느린 경로(220)로 보내진 데이터를 빠른 경로(210)로 모두 재전송으로 중복해서 전송할 가능성이 있다. 따라서, 상기 가능성을 최소화하기 위해 느린 경로(220)의 TCP 혼잡 윈도우 값을 절반으로 줄이는 기능을 함께 사용할 수 있다(Penalization). 그럼에도, 두 경로(210, 220) 가 동시에 사용되는 경우, 빠른 경로(210)로 데이터를 전송하는 것이 빈번히 제한될 수 있다.
예를 들면, 802.11ac 표준에서 수백 Mbps 정도의 속도인 Wifi를 통해 전송하는 경우, 수 배의 RTT 차이만으로도 단말이 가지는 수신 버퍼를 쉽게 채울 수 있다. 따라서, 상기 wifi 경로 및 다른 경로의 병합 성능 저하가 빈번히 발생할 수 있다. 수신 버퍼의 크기가 매우 크다면 성능 저하의 문제가 발생하지 않을 수도 있다. 그러나 일반적으로 단말이 가지는 메모리 크기에 제한이 있기 때문에, TCP 수신 버퍼의 크기를 경로 별 속도 차이의 영향을 받지 않을 정도로 증가하기에는 어려움이 존재할 수 있다.
따라서, 상술한 문제점을 해결하기 위해, 이하에서는, 복수의 경로 간 속도 차이가 많이 나는 환경에서, 다중 경로 전송을 수행할 경우, 수신 버퍼의 크기에 상관없이 최소한 빠른 경로의 속도를 보장해 줄 수 있는 패킷 스케줄링 방법을 설명한다.
구체적으로, 느린 경로를 사용함으로써 수신 버퍼가 제한되는 상황이 예상이 되면, 장치의 스케줄러는 느린 경로로의 패킷 스케줄링을 제한하고, 추후 느린 경로의 상황이 개선되면 다시 스케줄링을 수행할 수 있다. 따라서, 어느 한 경로가 매우 혼잡해지거나 느려지는 경우에도 buffer-blocking으로 인해 다른 경로의 속도가 저하되는 문제를 해결할 수 있다.
도 3은 본 발명의 일 실시 예에 따른, 데이터를 송수신하는 장치의 구성요소를 도시한 도면이다.
도 3에 도시된 MPTCP 송신자(sender)(300)는 스케줄링에 필요한 정보를 수집하는 경로 모니터부(Path Monitor)(310)와 Buffer-blocking을 회피하도록 고안된 스케줄러(320)를 포함할 수 있다.
구체적으로, 경로 모니터부(310)는 Buffer-Blocking 상황을 감지하기 위해 필요한 정보를 수집할 수 있다. 예를 들면, 수신 장치의 버퍼 상태 정보와 송신 측의 subflow에 대한 전송 관련 정보(예를 들면 RTT, 혼잡 윈도우 등)를 확인할 수 있다. 상기 정보는 TCP의 경우 ACK과 같은 피드백을 통해 획득할 수 있으며, 다른 측정 네트워크 요소(Measurement Network Element)(301)를 통해 획득할 수도 있다. 예를 들면 경로 모니터부(310)는 기지국(302), DPI(303) 또는 Analytics 장비(304)로부터 네트워크의 혼잡 상황이나 다운링크 전송률에 대한 정보를 수신할 수 있다. 그리고 스케줄러(320)는 상기 수신된 정보를 스케줄링 시 이용할 수 있다.
한편, 스케줄러(320)의 버퍼 블록킹(Buffer-Blocking) 감지부(321)는 상기 경로 모니터부(310)를 통해 획득한 정보를 바탕으로, 수신 버퍼의 막힘 현상 발생 여부를 판단할 수 있다(Buffer-Blocking Detection).
판단 결과, 상기 수신 버퍼의 막힘 현상이 발생할 것으로 판단되면, 상기 스케줄러(320)는 느린 subflow로의 스케줄링을 중지할 수 있다. 그러나 추후에 경로의 상황(예를 들면, 전송 속도)이 바뀔 것을 대비해 스케줄링을 제한한 subflow에 대해서도 RTT 등 전송 관련 정보를 최신 값으로 유지할 필요가 있다. 예를 들면, 상기 스케줄러(320)의 경로 프로빙 관리부(Path Probing Management)(322)에서 Path probing 용으로 패킷 스케줄링을 허가하도록 관리할 수 있다. 따라서, Buffer-Blocking이 발생하지 않도록 느린 subflow로 스케줄링 된 Probing 용 데이터를 곧바로 빠른 subflow로 재전송하는 기능을 수행할 수 있다.
MPTCP 송신자(sender)의 스케줄러(320)가 수신 버퍼의 막힘 현상 발생 여부를 판단하는 방법을 구체적으로 설명한다. 예를 들면, 스케줄러(320)는 응용 계층 (Application Layer) 에서 내려온 데이터를 각각의 subflow로 스케줄링할 때, 하기와 같은 동작을 수행할 수 있다.
구체적으로, 스케줄러(320)의 경로 모니터부(321)는 빠른 경로의 RTT 당 전송 가능한 패킷 개수(TxDatafast), 빠른 경로의 RTT (Round-Trip Time)(Delayfast), 느린 경로의 RTT (Round-Trip Time)(Delay slow), 빠른 경로의 MSS (Maximum Segment Size)(MSS fast), 빠른 경로 상에 전송 중인 패킷 개수(in_ flight fast), 느린 경로 상에 전송 중인 패킷 개수(in_flight slow) 및 수신 버퍼 크기(rwnd)를 획득할 수 있다.
상기 경로 모니터부(321)는 응용 계층 (Application Layer) 에서 내려온 데이터를 각각의 subflow로 스케줄링할 때마다, 상기의 정보를 업데이트할 수 있다.
또한, 스케줄러(320)의 버퍼 블록킹(Buffer-Blocking) 감지부(321)는 상기 경로 모니터부(310)를 통해 획득한 정보를 바탕으로, 수신 버퍼의 막힘 현상 발생 여부를 판단할 수 있다(Buffer-Blocking Detection).
구체적으로, 버퍼 블록킹(Buffer-Blocking) 감지부(321)는 상기 Delay slow 기간에 빠른 경로로 전송될 수 있는 데이터 크기 rcv _ queued fast를 수학식 1에 따라, 계산할 수 있다.
수학식 1
Figure PCTKR2017007514-appb-M000001
상기 수학식 1의 상기 TxData fast는 상기 빠른 경로로 기준 시간(RTT) 동안 전송 가능한 패킷의 개수이며, 상기 Delay slow는 느린 경로에 대한 기준 시간(RTT)이고, 상기 Delay fast는 상기 빠른 경로에 대한 기준 시간(RTT)이며, 상기 MSS fast는 상기 빠른 경로에 대한 최대 세그먼트 사이즈(maximum segment size, MSS)일 수 있다. 또는, 상기 MSS fast는 상기 빠른 경로에 대한 전송 패킷 한 개의 크기로 볼 수도 있다.
상기 TxData fast는 빠른 경로 및 느린 경로의 혼잡 상황에 따라 변할 수 있는 값이다. 예를 들면, TCP에 적용되는 경우, 상기 TxData fast는 min(in_ flight fast, cwnd fast/2) 등 (cwnd fast는 빠른 경로의 혼잡 윈도우)으로 적용하여 사용될 수 있다.
이때, 도 4에 도시된 바와 같이, 스케줄러(320)는 상기 TxData fast의 값과 수신 버퍼 크기(rwnd)를 비교하여, 전송 상태(또는 전송 모드)를 결정할 수 있다. 예를 들면, 상기 스케줄러(320)는 느린 경로를 통한 스케줄링을 제한할지를 결정할 수 있다.
예를 들면, 상기 스케줄러(320)는 빠른 경로 및 느린 경로 모두를 이용하여 데이터를 전송하도록 스케줄링 상태를 일반(normal) 상태로 결정할 수 있다. 그리고 상기 스케줄러(320)는 느린 경로에 대해 스케줄링을 제한하는 상태를 프루닝(pruning) 상태로 결정할 수 있다.
구체적으로, 상기 TxData fast의 값이 수신 버퍼 크기(rwnd)보다 작거나 같은 경우, 스케줄러(320)는 normal 상태에서, 기존의 스케줄링 알고리즘을 그대로 사용할 수 있다. 예를 들면, 상기 TxData fast의 값이 수신 버퍼 크기(rwnd)보다 작은 경우에는, 느린 경로를 사용하더라도 빠른 경로의 전송이 제약되지 않을 수 있으므로, 상기 스케줄러(320)는 normal 상태를 유지하거나, 상기 normal 상태로 전이할 수 있다.
한편, 상기 TxData fast의 값이 수신 버퍼 크기(rwnd)보다 큰 경우, 스케줄러(320)는 pruning 상태로 전이하여, 느린 경로로 스케줄링을 제한할 수 있다. 예를 들면, 상기 TxData fast의 값이 수신 버퍼 크기(rwnd)보다 큰 경우, 상기 수신 버퍼에 대한 막힘 현상이 발생할 수 있다. 따라서, 스케줄러(320)는 pruning 상태로 전이하여, Probing 수행을 위한 데이터 패킷 전송 외에는, 상기 느린 경로로 데이터 전송을 위한 스케줄링을 수행하지 않을 수 있다.
도 5는 본 발명의 일 실시 예에 따라, Probing 동작을 설명하기 위한 도면이다.
구체적으로, 상기 pruning 상태에서, 상기 스케줄러(320)는 느린 경로로의 Probing을 수행할 수 있다. 예를 들면, 상기 스케줄러(320)는 느린 경로의 RTT를 지속적으로 측정하고, in_ flight slow가 0이 될 때마다(또는 RTT마다) 한 번씩 느린 경로로 스케줄링을 허용할 수 있다. 상기 느린 경로로 스케줄링이 허용되면, 상기 in_flight slow는 0 이상이 되며, 상기 스케줄러(320)는 상기 느린 경로로 전송된 패킷을 빠른 경로로 곧바로 재전송할 수 있다. 구체적으로, 스케줄링 된 패킷 전송으로 인해 수신 버퍼 막힘 현상이 발생할 수 있으므로, 상기 스케줄러(320)는 상기 느린 경로로 스케줄링 된 패킷과 동일한 패킷을 빠른 경로로 재전송하여 수신 버퍼 막힘을 막을 수 있다.
도 5에 도시된 바와 같이, Pruning 상태인 동안, 3번 패킷을 스케줄링하려는 시점에 in_ flight slow가 0인 상황을 가정하면, 스케줄러(320)는 3번 패킷(501)을 느린 경로(510)로 스케줄링하여 전송할 수 있다. 그리고 스케줄러(320)는 곧바로 빠른 경로(520)로 3번 패킷(501)을 재전송하여 수신 버퍼 막힘이 발생하는 것을 방지할 수 있다. 이후의 4번 패킷부터는 in_ flight slow가 0 이상이 되기 때문에 다시 빠른 경로(520)로만 패킷 스케줄링을 수행할 수 있다.
느린 경로(510)를 통한 패킷이 전송되어, 상기 3번 패킷(501)이 수신 장치에 두 번 도착하여도, 상기 수신 장치는 중복되어 수신된 패킷 중에서, 하나의 패킷을 폐기할 수 있다.
또한, 상기 스케줄러(320)는 상기 느린 경로(510)로의 Probing 동작을 통해, 상기 느린 경로(510)의 전송 속도가 여전히 느린 것으로 판단할 수 있다. 구체적으로, 상기 수신 버퍼(530)를 포함하는 수신 장치로부터, 상기 3번 패킷에 대한 피드백(예를 들면, ACK)이 수신되면, 장치는 상기 느린 경로(510)의 RTT를 측정할 수 있다. 그리고 상기 측정된 결과에 기반하여, 상기 스케줄러(320)는 다음번 스케줄링 수행 시에, 상기 수학식 1에 따라, 전송 상태를 결정할 수 있다.
따라서, 상기 스케줄러(320)는 Pruning 상태 유지 또는 normal 상태로의 변경을 결정할 수 있게 된다.
한편, RTT 측정(measurement) 방식에 있어, 일반적으로 TCP는 RTT 샘플 값 (RTT)을 얻을 때마다 수학식 2에 따라, RTT 대푯값 (smoothed RTT)을 계산할 수 있다.
수학식 2
Figure PCTKR2017007514-appb-M000002
예를 들면, 운영체제(Linux)에서는
Figure PCTKR2017007514-appb-I000001
값으로 0.875 (7/8)을 사용할 수 있다. 즉 새로 측정된 RTT 샘플 값에 1/8의 낮은 비중을 주어 업데이트를 할 수 있다.
한편, 본 발명의 일 실시 예에 따르면, Pruning 상태에서 느린 경로의 smoothed_RTT를 업데이트 할 경우, 매우 적은 수의 Probing 패킷만을 사용해야 할 수 있다. 따라서, 현재 변화하는 경로 정보를 빠르게 반영하기 위해서는 대푯값보다 샘플 값에 더 높은 비중을 주는 것이 바람직할 수 있다. Probing 패킷에 의해 smoothed_RTT 값을 업데이트 할 시에는 7/8보다 낮은
Figure PCTKR2017007514-appb-I000002
값을 사용할 수 있다. (예를 들면,
Figure PCTKR2017007514-appb-I000003
값으로 1/8을 사용할 수 있다.)
상기
Figure PCTKR2017007514-appb-I000004
값이 1/8 또는 7/8인 것은 일 실시 예에 불과할 뿐,
Figure PCTKR2017007514-appb-I000005
값은 0초과 1미만의 실수일 수 있다.
한편, 전술한 발명의 실시 예는 두 개의 경로에 대해, 하나의 경로가 빠르고, 다른 하나의 경로가 느린 경우를 가정하여 설명하였다. 본 발명의 다른 실시 예에 따르면, 속도가 다른 셋 이상의 다중 경로 전송에도 상술한 방법이 적용될 수 있다.
예를 들면, 1부터 n까지 RTT가 빠른 순으로 subflow가 존재한다고 할 때, 상기 수학식 1에 따라 계산된 rcv _ queued fast 를 특정 경로 r (1≤r≤N)에 대한 rcv_queuedr fast 로 확장할 수 있다. 그리고 스케줄러(300)는 경로 r을 사용함으로써 경로 1부터 r-1 상에 buffer-blocking으로 인한 속도 저하가 생길 수 있는지 판단할 수 있다.
구체적으로, 스케줄러(300)는 rcv _ queuedr fast 를 수학식 3과 같이 계산할 수 있다.
수학식 3
Figure PCTKR2017007514-appb-M000003
따라서, 스케줄러(300)는 rcv _ queuedr fast 가 rwnd 보다 클 경우, 경로 r을 느린 경로로 규정할 수 있다. 그리고 스케줄러(300)는 상기 느린 경로로 결정된 경로에 대해, 전술한 바와 같은 Pruning 상태에서의 동작을 수행할 수 있다.
한편, 본 발명의 실시 예에 따른 동작들은 스케줄러(300) 및 상기 스케줄러(300)에 포함된 버퍼 블록킹 감지부(321) 및/또는 경로 프로빙 관리부 (322)를 통해 수행되는 것으로 설명하였으나, 이는 일 실시 예에 불과할 뿐, 각 동작을 수행하는 구성요소의 명칭을 국한하는 것은 아니다. 예를 들면, 전술한 동작은 장치의 제어부 또는 프로세서 등에 의해 수행될 수 있다.
전술한 본 발명의 일 실시 예에 따른 스케줄링 방법은 MPTCP 또는 다중 경로 전송을 수행하는 모든 종류의 서버 또는 단말에 적용 가능하다. 도 6은 MPTCP (또는 다중 경로 전송이 가능한) 프록시 서버(Proxy server)에 본 발명을 적용했을 때의 실시 예를 나타낸 도면이다.
구체적으로, 단말(600)은 먼저 다중 연결을 통해 MPTCP Proxy server와 연결하고, MPTCP Proxy server(610)에서 다시 단말이 연결하고자 하는 최종 목적지와 TCP를 사용하여 연결을 맺을 수 있다. 그리고 상기 MPTCP Proxy server(610)는 상기 단말(600)과의 연결 및 상기 최종 목적지와의 연결 사이에서 릴레이를 수행할 수 있다. (만약 최종 목적지 서버에서 다중 경로 전송을 지원한다면 프록시 없이 단말과 최종 목적지 서버 간의 직접적인 다중 경로 전송이 가능하며, 이 경우 본 발명의 실시 예는 최종 목적지 서버에 적용될 수 있다.) MPTCP Proxy server(610)는 모바일 네트워크(Mobile network) 또는 모바일 네트워크(Mobile network)의 바로 뒤 (예를 들면 SGi와 연결), 또는 Internet 상에 존재할 수 있다. 만약, MPTCP Proxy server(610)가 Mobile network 상에 존재하는 경우, 상기 MPTCP Proxy server(610)는 기지국이나 다른 measurement element로부터 네트워크 상태에 대한 더욱 정확한 정보를 받아, 패킷 스케줄링 시에 이를 활용할 수 있다. 그렇지 않았으면, 기존의 TCP에서 데이터 전송 시 측정되는 RTT, 수신 버퍼 크기 등의 정보를 활용하여 MPTCP Proxy server(610)가 패킷 스케줄링을 수행할 수 있다.
한편, 도 7a 및 도 7b는 본 발명의 일 실시 예에 따른 효과를 설명하는 도면이다.
도 7a 및 도 7b에 도시된 결과는, 클라이언트와 서버 양단 사이에 프록시 서버(Proxy server)를 두고, 클라이언트와 Proxy server는 MPTCP를 지원하며, 서버는 지원하지 않는 경우에 의한 예시이다. 이때, 클라이언트는 Proxy를 거쳐 서버와 통신하며, Proxy는 클라이언트와는 MPTCP 연결을, 서버와는 일반 TCP 연결을 맺고 상기 클라이언트 및 서버 사이의 릴레이(relay)를 수행하는 실시 예에 의한 것일 수 있다.
도 7a는 일반적인 방법에 의해 스케줄링을 수행한 결과를 나타낸 도면이다. 그리고 도 7b는 상기 Proxy server가 본원 발명의 실시 예에 따라 스케줄링 동작을 수행하는 경우의 결과는 나타낸 도면이다.
도 7a에서 Path1 딜레이가 30ms일 때 Path1-only 성능은 149Mbps이고, Path2 딜레이가 6ms일 때 Path2-only 성능은 497Mbps이다. 따라서 딜레이가 (30ms, 6ms)일 때의 이상적인 병합 성능은 149+497=646Mbps일 수 있다.
도 7a에 도시된 바와 같이, Path1 딜레이가 100ms을 넘어가기 시작하는 시점에서 병합 속도가 Path2-only 성능보다 늦어지기 시작한 것을 볼 수 있다.
반면, 도 7b에 도시된 바와 같이, 본 발명의 일 실시 예에 따른, MPTCP 성능은 딜레이 차이에 상관없이 최소 Path2-only 성능에 근접한 성능이 나옴을 확인할 수 있다.
한편, 도 8은 본 발명의 일 실시 예에 따른, 장치의 방법을 나타내는 흐름도이다.
먼저, 단계 S800에서, 장치는 제2 경로의 기준 시간 동안에 제1 경로로 전송할 수 있는 데이터의 크기를 확인할 수 있다. 구체적으로 제2 경로는 제1 경로보다 전송 속도가 느린 경로이고, 제1 경로는 제2 경로보다 전송 속도가 빠른 경로일 수 있다. 예를 들면, 장치는 전술한 수학식 1을 이용하여 제2 경로의 기준 시간 동안에 제1 경로로 전송할 수 있는 데이터의 크기를 확인할 수 있다.
단계 S805에서, 장치는 확인된 데이터의 크기가 수신 장치의 버퍼 크기 초과하는지 여부를 판단할 수 있다. 예를 들면, 장치는 수신 장치로 전송한 데이터 패킷에 대한 ACK 신호가 수신되면, 상기 ACK 신호에 포함된 정보를 바탕으로 상기 수신 장치의 버퍼 크기를 확인할 수 있다. 따라서, 장치는 상기 확인된 데이터의 크기가 상기 수신 장치의 버퍼 크기를 초과하는지 여부를 판단할 수 있다.
판단 결과, 상기 확인된 데이터의 크기가 상기 수신 장치의 버퍼 크기를 초과하는 경우, 단계 S810에서, 장치는 제2 모드로 전송 모드를 결정할 수 있다. 그리고 단계 S815에서, 장치는 상기 제2 모드에 따라, 제2 경로보다 데이터 전송 속도가 빠른 제1 경로를 통해 수신 장치로 데이터를 전송하도록 스케줄링을 수행하고, 제2 경로로의 데이터의 스케줄링을 제한할 수 있다.
구체적으로, 상기 제2 모드는, 장치가 상기 제1 경로로 데이터 패킷을 전송하도록 스케줄링하면서, 기설정된 간격으로, 상기 제1 경로로 전송하는 임의의 패킷을 상기 제2 경로를 통해 전송하도록 스케줄링하는 모드일 수 있다.
따라서, 단계 S820에서, 장치는 제2 모드로 데이터를 스케줄링하는 동안, 제1 경로 및 제2 경로를 통해 상기 임의의 패킷을 전송할 수 있다. 예를 들면, 장치는 제2 경로의 RTT 당 한 번씩, 임의의 패킷을 상기 제1 경로 및 상기 제2 경로를 통해 전송할 수 있다.
그리고 단계 S825에서, 장치는 상기 임의의 패킷의 전송에 따라, 제2 경로의 기준 시간 동안 제1 경로로 전송할 수 있는 데이터의 크기를 확인할 수 있다.
상기 임의의 패킷의 전송에 의해, 상기 제2 경로의 기준 시간 동안 상기 제1 경로로 전송할 수 있는 데이터의 크기를 확인한 장치는, 다시 단계 S805로 진행할 수 있다.
한편, 상기 단계 S805에서, 확인된 데이터의 크기가 수신 장치의 버퍼 크기 초과하지 않는 것으로 판단되면, 장치는 단계 S830으로 진행하여, 제1 모드로 전송 모드를 결정할 수 있다.
따라서, 단계 S835에서, 장치는 제1 경로 및 제2 경로를 통해 수신 장치로 데이터를 전송하도록 스케줄링할 수 있다. 예를 들면, 장치는 일반적인 MPCTP 방식에 의해 데이터를 전송하도록 스케줄링을 수행할 수 있다.
도 8에 도시된 장치의 제어 방법은 장치에 의해 수행되는 것으로 설명하였으나, 상기 각 단계는 장치, 장치의 제어부 또는 장치의 스케줄러 등에 의해 수행될 수도 있다.
한편, 도 9는 본 발명의 일 실시 예에 따른 전송 장치(900)의 구성요소를 도시한 블록도이다.
전송 장치(900)는 송수신부(910) 및 제어부(920)를 포함할 수 있다. 송수신부(910)는 신호를 송수신하기 위한 구성요소이다.
또한, 제어부(920)는 전송 장치(900)를 전반적으로 제어할 수 있다.
구체적으로, 제어부(920)는 상기 제2 경로의 기준 시간 동안, 상기 제1 경로로 전송할 수 있는 데이터의 크기를 확인할 수 있다. 그리고 상기 확인된 데이터의 크기 및 수신 장치의 버퍼 크기를 비교할 수 있다. 제어부(920)는 상기 비교 결과에 기반하여 전송 모드를 결정하고, 상기 결정된 전송 모드에 따라 상기 수신 장치로 데이터를 전송할 수 있다.
한편, 제어부(920)는 상기 확인된 데이터의 크기가 상기 수신 장치의 버퍼크기 이하인 경우, 상기 제1 경로 및 상기 제2 경로를 통해 상기 수신 장치로 데이터를 전송하도록 스케줄링하는 제1 모드로 결정할 수 있다.
또한, 제어부(920)는 상기 확인된 데이터의 크기가 상기 수신 장치의 버퍼크기 초과인 경우, 상기 제2 경로보다 데이터 전송 속도가 빠른 상기 제1 경로를 통해 상기 수신 장치로 데이터를 전송하도록 스케줄링하고, 상기 제2 경로로의 데이터의 스케줄링을 제한하는 제2 모드로 결정할 수 있다.
상기 제2 경로로의 데이터의 스케줄링을 제한하는 것은, 상기 제1 경로로 데이터 패킷을 전송하도록 스케줄링하면서, 기설정된 간격으로, 상기 제1 경로로 전송하는 임의의 패킷을 상기 제2 경로를 통해 전송하도록 스케줄링하는 것일 수 있다.
또한, 제어부(920)는 상기 제2 모드로 동작하는 동안, 상기 제1 경로 및 상기 제2 경로를 통해 임의의 패킷을 전송하고, 상기 임의의 패킷의 전송에 따라 상기 제2 경로의 기준 시간 동안, 상기 제1 경로로 전송할 수 있는 데이터의 크기를 확인할 수 있다. 그리고 제어부(920)는 상기 확인 결과에 기반하여, 상기 제2 경로로의 데이터 전송 여부를 결정할 수 있다.
그리고 상기 확인 결과, 상기 임의의 패킷의 전송에 따라 상기 제2 경로의 기준 시간 동안 상기 제1 경로로 전송할 수 있는 데이터의 크기가 상기 수신 장치의 버퍼크기 이하인 경우, 제어부(920)는 상기 제1 경로 및 상기 제2 경로를 통해 상기 수신 장치로 데이터를 전송하는 제1 모드로 전환할 수 있다.
반면, 상기 확인 결과, 상기 데이터의 크기가 상기 수신 장치의 버퍼크기 초과인 경우, 제어부(920)는 상기 제2 모드를 유지할 수 있다.
또한, 상기 비교하는 특징은, 전술한 바와 같이 수학식 1에 따라, 상기 데이터의 크기 및 상기 수신 장치의 버퍼 크기를 비교할 수 있다.
한편, 상기 기준 시간은 임의의 경로로 데이터 패킷을 전송하고, 상기 수신 장치로부터 상기 전송된 데이터 패킷에 대한 피드백 신호가 수신될 때까지 소요되는 시간(round-trip time, RTT)일 수 있다.
상술한 전송 장치(900)에 의하면, 경로 간 속도 차이가 많이 나는 환경에서 다중 경로 전송을 수행하는 경우에도, 수신 버퍼 크기에 상관없이, 최소한 빠른 경로의 전송 속도를 보장할 수 있게 된다.
한편, 상술한 다양한 실시 예들에 따른 장치의 스케줄링 방법은 소프트웨어로 코딩되어 비일시적 판독 가능 매체(non-transitory readable medium)에 저장될 수 있다. 이러한 비일시적 판독 가능 매체는 다양한 장치에 탑재되어 사용될 수 있다.
비일시적 판독 가능 매체란 레지스터, 캐쉬, 메모리 등과 같이 짧은 순간 동안 데이터를 저장하는 매체가 아니라 반영구적으로 데이터를 저장하며, 기기에 의해 판독(reading)이 가능한 매체를 의미한다. 구체적으로는, CD, DVD, 하드 디스크, 블루레이 디스크, USB, 메모리카드, ROM 등이 될 수 있다.
또한, 이상에서는 본 발명의 바람직한 실시 예에 대하여 도시하고 설명하였지만, 본 발명은 상술한 특정의 실시 예에 한정되지 아니하며, 청구범위에서 청구하는 본 발명의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 본 발명의 기술적 사상이나 전망으로부터 개별적으로 이해되어져서는 안 될 것이다.

Claims (15)

  1. 제1 경로 및 제2 경로 중 적어도 하나를 통해 데이터를 전송하는 장치의 데이터 전송 방법에 있어서,
    상기 제2 경로의 기준 시간 동안, 상기 제1 경로로 전송할 수 있는 데이터의 크기를 확인하는 단계;
    상기 확인된 데이터의 크기 및 수신 장치의 버퍼 크기를 비교하는 단계; 및
    상기 비교 결과에 기반하여 전송 모드를 결정하고, 상기 결정된 전송 모드에 따라 상기 수신 장치로 데이터를 전송하는 단계; 를 포함하는 방법.
  2. 제1항에 있어서,
    상기 전송하는 단계는,
    상기 확인된 데이터의 크기가 상기 수신 장치의 버퍼크기 이하인 경우, 상기 제1 경로 및 상기 제2 경로를 통해 상기 수신 장치로 데이터를 전송하도록 스케줄링 하는 제1 모드로 결정하는 단계; 를 더 포함하는 것을 특징으로 하는 방법.
  3. 제1항에 있어서,
    상기 전송하는 단계는,
    상기 확인된 데이터의 크기가 상기 수신 장치의 버퍼크기 초과인 경우, 상기 제2 경로보다 데이터 전송 속도가 빠른 상기 제1 경로를 통해 상기 수신 장치로 데이터를 전송하도록 스케줄링 하고, 상기 제2 경로로의 데이터의 스케줄링을 제한하는 제2 모드로 결정하는 단계; 를 더 포함하는 것을 특징으로 하는 방법.
  4. 제3항에 있어서,
    상기 제2 경로로의 데이터의 스케줄링을 제한하는 것은,
    상기 제1 경로로 데이터 패킷을 전송하도록 스케줄링 하면서, 기설정된 간격으로, 상기 제1 경로로 전송하는 임의의 패킷을 상기 제2 경로를 통해 전송하도록 스케줄링 하는 것을 특징으로 하는 방법.
  5. 제3항에 있어서,
    상기 제2 모드로 동작하는 동안, 상기 제1 경로 및 상기 제2 경로를 통해 임의의 패킷을 전송하는 단계;
    상기 임의의 패킷의 전송에 따라 상기 제2 경로의 기준 시간 동안, 상기 제1 경로로 전송할 수 있는 데이터의 크기를 확인하는 단계; 및
    상기 확인 결과에 기반하여, 상기 제2 경로로의 데이터 전송 여부를 결정하는 단계; 를 더 포함하는 것을 특징으로 하는 방법.
  6. 제5항에 있어서,
    상기 결정하는 단계는,
    상기 확인 결과, 상기 임의의 패킷의 전송에 따라 상기 제2 경로의 기준 시간 동안 상기 제1 경로로 전송할 수 있는 데이터의 크기가 상기 수신 장치의 버퍼크기 이하인 경우, 상기 제1 경로 및 상기 제2 경로를 통해 상기 수신 장치로 데이터를 전송하는 제1 모드로 전환하는 단계; 및
    상기 데이터의 크기가 상기 수신 장치의 버퍼크기 초과인 경우, 상기 제2 모드를 유지하는 단계; 를 더 포함하는 것을 특징으로 하는 방법.
  7. 제1항에 있어서,
    상기 비교하는 단계는,
    하기의 식에 따라, 상기 데이터의 크기 및 상기 수신 장치의 버퍼 크기를 비교하며,
    Figure PCTKR2017007514-appb-I000006
    상기 Rcv _ queued fast는 제2 경로의 기준 시간 동안, 제1 경로로 전송할 수 있는 데이터의 크기이고, 상기 TxData fast는 상기 제1 경로로 상기 기준 시간 동안 전송 가능한 패킷의 개수이며, 상기 Delay slow는 상기 제2 경로에 대한 기준 시간이고, 상기 Delay fast는 상기 제1 경로에 대한 기준 시간이며, 상기 MSS fast는 상기 제1 경로에 대한 최대 세그먼트 사이즈(maximum segment size, MSS)이고,
    상기 기준 시간은 임의의 경로로 데이터 패킷을 전송하고, 상기 수신 장치로부터 상기 전송된 데이터 패킷에 대한 피드백 신호가 수신될 때까지 소요되는 시간(round-trip time, RTT)인 것을 특징으로 하는 방법.
  8. 제1 경로 및 제2 경로 중 적어도 하나를 통해 데이터를 전송하는 장치에 있어서,
    신호를 송수신하는 송수신부; 및
    상기 제2 경로의 기준 시간 동안, 상기 제1 경로로 전송할 수 있는 데이터의 크기를 확인하고, 상기 확인된 데이터의 크기 및 수신 장치의 버퍼 크기를 비교하며 상기 비교 결과에 기반하여 전송 모드를 결정하고, 상기 결정된 전송 모드에 따라 상기 수신 장치로 데이터를 전송하도록 상기 송수신부를 제어하는 제어부; 를 포함하는 장치.
  9. 제8항에 있어서,
    상기 제어부는,
    상기 확인된 데이터의 크기가 상기 수신 장치의 버퍼크기 이하인 경우, 상기 제1 경로 및 상기 제2 경로를 통해 상기 수신 장치로 데이터를 전송하도록 스케줄링 하는 제1 모드로 결정하는 것을 특징으로 하는 장치.
  10. 제8항에 있어서,
    상기 제어부는,
    상기 확인된 데이터의 크기가 상기 수신 장치의 버퍼크기 초과인 경우, 상기 제2 경로보다 데이터 전송 속도가 빠른 상기 제1 경로를 통해 상기 수신 장치로 데이터를 전송하도록 스케줄링 하고, 상기 제2 경로로의 데이터의 스케줄링을 제한하는 제2 모드로 결정하는 것을 특징으로 하는 장치.
  11. 제10항에 있어서,
    상기 제2 경로로의 데이터의 스케줄링을 제한하는 것은,
    상기 제1 경로로 데이터 패킷을 전송하도록 스케줄링 하면서, 기설정된 간격으로, 상기 제1 경로로 전송하는 임의의 패킷을 상기 제2 경로를 통해 전송하도록 스케줄링 하는 것을 특징으로 하는 장치.
  12. 제10항에 있어서,
    상기 제어부는,
    상기 제2 모드로 동작하는 동안, 상기 제1 경로 및 상기 제2 경로를 통해 임의의 패킷을 전송하도록 상기 송수신부를 제어하고, 상기 임의의 패킷의 전송에 따라 상기 제2 경로의 기준 시간 동안, 상기 제1 경로로 전송할 수 있는 데이터의 크기를 확인하며, 상기 확인 결과에 기반하여, 상기 제2 경로로의 데이터 전송 여부를 결정하는 것을 특징으로 하는 장치.
  13. 제12항에 있어서,
    상기 제어부는,
    상기 확인 결과, 상기 임의의 패킷의 전송에 따라 상기 제2 경로의 기준 시간 동안 상기 제1 경로로 전송할 수 있는 데이터의 크기가 상기 수신 장치의 버퍼크기 이하인 경우, 상기 제1 경로 및 상기 제2 경로를 통해 상기 수신 장치로 데이터를 전송하는 제1 모드로 전환하고, 상기 데이터의 크기가 상기 수신 장치의 버퍼크기 초과인 경우, 상기 제2 모드를 유지하도록 제어하는 것을 특징으로 하는 방법.
  14. 제8항에 있어서,
    상기 제어부는,
    하기의 식에 따라, 상기 데이터의 크기 및 상기 수신 장치의 버퍼 크기를 비교하며,
    Figure PCTKR2017007514-appb-I000007
    상기 Rcv _ queued fast는 제2 경로의 기준 시간 동안, 제1 경로로 전송할 수 있는 데이터의 크기이고, 상기 TxData fast는 상기 제1 경로로 상기 기준 시간 동안 전송 가능한 패킷의 개수이며, 상기 Delay slow는 상기 제2 경로에 대한 기준 시간이고, 상기 Delay fast는 상기 제1 경로에 대한 기준 시간이며, 상기 MSS fast는 상기 제1 경로에 대한 최대 세그먼트 사이즈(maximum segment size, MSS)인 것을 특징으로 하는 장치.
  15. 제8항에 있어서,
    상기 기준 시간은 임의의 경로로 데이터 패킷을 전송하고, 상기 수신 장치로부터 상기 전송된 데이터 패킷에 대한 피드백 신호가 수신될 때까지 소요되는 시간(round-trip time, RTT)인 것을 특징으로 하는 장치.
PCT/KR2017/007514 2016-07-28 2017-07-13 무선 통신 시스템에서 데이터의 전송 방법 및 장치 WO2018021734A1 (ko)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP17834677.1A EP3471354A4 (en) 2016-07-28 2017-07-13 METHOD AND DEVICE FOR DATA TRANSMISSION IN A WIRELESS COMMUNICATION SYSTEM
US16/316,464 US11252608B2 (en) 2016-07-28 2017-07-13 Method and apparatus for transmitting data in wireless communication system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2016-0096458 2016-07-28
KR1020160096458A KR102568436B1 (ko) 2016-07-28 2016-07-28 무선 통신 시스템에서 데이터의 전송 방법 및 장치

Publications (1)

Publication Number Publication Date
WO2018021734A1 true WO2018021734A1 (ko) 2018-02-01

Family

ID=61017122

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2017/007514 WO2018021734A1 (ko) 2016-07-28 2017-07-13 무선 통신 시스템에서 데이터의 전송 방법 및 장치

Country Status (4)

Country Link
US (1) US11252608B2 (ko)
EP (1) EP3471354A4 (ko)
KR (1) KR102568436B1 (ko)
WO (1) WO2018021734A1 (ko)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018149581A1 (en) * 2017-02-15 2018-08-23 Nokia Solutions And Networks Oy Network multi-path proxy selection to route data packets
CN108540380B (zh) * 2017-03-02 2021-08-20 华为技术有限公司 多子流网络传输方法及装置
CN111416794B (zh) * 2019-01-08 2022-07-29 华为技术有限公司 一种数据传输方法及电子设备
TWI708488B (zh) * 2019-08-20 2020-10-21 智易科技股份有限公司 傳輸系統、傳送裝置及傳輸路徑分配方法
EP3832983B1 (en) * 2019-12-05 2023-01-04 Voysys AB Method and system for reducing latency between an automated vehicle and a remote terminal
KR102626729B1 (ko) * 2021-11-03 2024-01-17 연세대학교 산학협력단 무선 네트워크 mptcp 혼잡 윈도우 제어 장치 및 방법

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20140077936A (ko) * 2011-09-22 2014-06-24 퀄컴 인코포레이티드 무선 통신 네트워크에서 다중경로 전송 접속을 위한 동적 서브플로우 제어
KR20140134936A (ko) * 2013-05-15 2014-11-25 삼성전자주식회사 무선 통신 시스템에서 데이터 패킷 송수신 방법 및 장치
KR20160036878A (ko) * 2014-09-26 2016-04-05 삼성전자주식회사 통신 시스템에서 데이터 흐름 제어 장치 및 방법

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6434620B1 (en) * 1998-08-27 2002-08-13 Alacritech, Inc. TCP/IP offload network interface device
US20070008884A1 (en) * 2003-10-08 2007-01-11 Bob Tang Immediate ready implementation of virtually congestion free guarantedd service capable network
CA2556420A1 (en) * 2004-02-19 2005-09-01 Georgia Tech Research Corporation Systems and methods for parallel communication
ATE457577T1 (de) * 2004-12-24 2010-02-15 Aspera Inc Massen-datentransfer
US10785117B2 (en) * 2009-06-11 2020-09-22 Talari Networks Incorporated Methods and apparatus for configuring a standby WAN link in an adaptive private network
US10476765B2 (en) * 2009-06-11 2019-11-12 Talari Networks Incorporated Methods and apparatus for providing adaptive private network centralized management system discovery processes
US9660912B2 (en) * 2010-02-19 2017-05-23 Thomson Licensing Control of packet transfer through a multipath session comprising a single congestion window
US9455897B2 (en) * 2010-04-06 2016-09-27 Qualcomm Incorporated Cooperative bandwidth aggregation using multipath transport
US8767625B2 (en) 2011-03-18 2014-07-01 Qualcomm Incorporated Method for concurrent bandwidth aggregation using a second path on a second wireless network that utilizes the packet core network of a first path on a first wireless network
KR102173084B1 (ko) * 2013-08-23 2020-11-02 삼성전자주식회사 무선 통신 시스템에서 데이터 패킷 송수신 방법 및 장치
BR112016004142B1 (pt) 2013-08-29 2022-05-17 Telefonaktiebolaget Lm Ericsson (Publ) Método, programador de protocolo de controle de transmissão de múltiplos trajetos, proxy de protocolo de controle de transmissão de múltiplos trajetos, rede de comunicação, e, meio legível por computador
US9385959B2 (en) * 2013-09-26 2016-07-05 Acelio, Inc. System and method for improving TCP performance in virtualized environments
US9979664B2 (en) * 2015-07-07 2018-05-22 Speedy Packets, Inc. Multiple protocol network communication
US20160323062A1 (en) * 2015-05-01 2016-11-03 Ubitus Inc. Packet recovery in interactive real-time media protocol
US20170034843A1 (en) * 2015-07-29 2017-02-02 Qualcomm Incorporated Scheduler methods for data aggregation over multiple links

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20140077936A (ko) * 2011-09-22 2014-06-24 퀄컴 인코포레이티드 무선 통신 네트워크에서 다중경로 전송 접속을 위한 동적 서브플로우 제어
KR20140134936A (ko) * 2013-05-15 2014-11-25 삼성전자주식회사 무선 통신 시스템에서 데이터 패킷 송수신 방법 및 장치
KR20160036878A (ko) * 2014-09-26 2016-04-05 삼성전자주식회사 통신 시스템에서 데이터 흐름 제어 장치 및 방법

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
FERLIN , SIMONE ET AL.: "BLEST: Blocking Estimation-based MPTCP Scheduler for Heterogeneous Networks", IFIP NETWORKING, 2016, Vienna, Austria ., pages 431 - 439, XP032915703, ISBN: 978-3-901882-83-8 *
KANG, HYEONG KYU ET AL.: "A Multi-connection TCP Scheme Supporting Idle Mode in Heterogeneous Mobile Networks", PROCEEDINGS OF THE 34TH KOREA INFORMATION PROCESSING SOCIETY FALL CONFERENCE, vol. 17, no. 2, 12 November 2010 (2010-11-12), pages 1070 - 1073, XP009511554 *

Also Published As

Publication number Publication date
EP3471354A1 (en) 2019-04-17
KR20180013174A (ko) 2018-02-07
EP3471354A4 (en) 2019-06-05
KR102568436B1 (ko) 2023-08-21
US11252608B2 (en) 2022-02-15
US20190297534A1 (en) 2019-09-26

Similar Documents

Publication Publication Date Title
WO2018021734A1 (ko) 무선 통신 시스템에서 데이터의 전송 방법 및 장치
US11432223B2 (en) Methods and apparatuses for selecting a first base station or a second base station to transmit a packet data unit (PDU) to a user equipment (UE)
WO2018194433A1 (ko) 이동 통신 네트워크 내 다중 링크 상에서의 패킷 분배 방법 및 장치
ES2761225T3 (es) Provisión de tratamiento de QoS basándose en múltiples peticiones
EP3531637B1 (en) Techniques for efficient reordering of data packets in multipath scenarios
EP3832976B1 (en) Radio bearer switching in radio access
CN113162727B (zh) 用于多链路通信的链路特定的块确认
US8838782B2 (en) Network protocol processing system and network protocol processing method
CN111066272B (zh) 移动无线电接入网络中的分组延迟减少
KR101983088B1 (ko) 다중 경로 환경에서의 udp 패킷 처리 방법
WO2019022418A1 (ko) 무선 통신 시스템에서 단말, 기지국 및 이의 통신 방법
WO2018012858A1 (ko) 무선 통신 시스템에서 데이터의 전송 속도 제어 방법 및 장치
US9385931B1 (en) Determining a reordering timer
Bhattacharyya et al. Effect of mode-switching on TCP short flows during D2D communication in LTE-A networks
WO2024060302A1 (en) Technologies for congestion signaling in wireless networks
US11870865B2 (en) Distributed proxy for encrypted transport protocol with efficient multi-priority multiplexed transport for improving user's traffic QoS
US11997179B2 (en) Distributed proxy for encrypted transport protocols with efficient multi-priority multiplexed transport for improving user's traffic QOS
WO2022139551A1 (ko) Harq 활성화 여부에 따른 타이머 동작 방법 및 장치
Zhang et al. Design of Reliable Parallel Transmission System in Complex Heterogeneous Network
US20210127301A1 (en) Application Notifications from Network for Throughput and Flow Control Adaptation
WO2023225172A1 (en) Distributed proxy for encrypted transport protocol with efficient multi-priority multiplexed transport for improving user's traffic qos
JP2009130624A (ja) 無線装置およびそれにおける通信方法
Nath Cross-layer design in cellular networks: issues and possible solutions.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17834677

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2017834677

Country of ref document: EP

Effective date: 20190108

NENP Non-entry into the national phase

Ref country code: DE