Service-defined multi-path scheduler

Abstract

The present invention relates to a 5G or 6G communication system for supporting a higher data transmission rate. The present invention proposes a method and apparatus for setting a multi-path scheduler defined by a service in a terminal and a network and activating same, in a mobile communication system.

Description

Service Definition Multipath Scheduler

[0001] The present invention relates to the operation of a terminal and a network entity in a mobile communication system, and more particularly, to a method and device for setting a multi-path scheduler defined by a service in a mobile communication system in a terminal and a network and activating the same.

[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] One embodiment of the present invention aims to provide a method for setting up a multi-path scheduler defined by a service in a terminal and a network and activating the same.

[0009] In addition, one embodiment of the present invention aims to provide a scheduler capable of dynamically distributing multiple service traffic on a packet basis through multiple paths.

[0010] In addition, one embodiment of the present invention aims to provide a method and device capable of applying ATSS technology according to characteristics of packets or packet groups within a flow.

[0011] In addition, one embodiment of the present invention aims to provide a method and device for setting a multi-path scheduler capable of performing multi-path scheduling between flows.

[0012] The technical problems to be achieved in the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned can be clearly understood by a person having ordinary skill in the technical field to which the present invention belongs from the description below.

[0013] In order to achieve the above object, a method performed by a core network entity of a communication system according to an embodiment of the present invention may include the steps of: receiving information on at least one multi-path scheduler set for at least one service from a data network entity providing the at least one service; determining at least one multi-path scheduler that can be provided to a terminal among the at least one multi-path scheduler set for the at least one service; transmitting an instance of a multi-path scheduler corresponding to a service requested by the terminal to the terminal; and activating the multi-path scheduler corresponding to the service requested by the terminal.

[0014] According to an embodiment, the at least one multi-path scheduler may determine a path along which transmission and reception are to be performed based on at least one of a flow-by-flow basis, a packet-by-packet basis, or a packet group-by-packet basis, and distribute the flow, packet, or packet group to the determined path.

[0015] According to an embodiment, the step of receiving information about the at least one multi-path scheduler set for the at least one service may include the step of receiving, from the data network, a code operable with the at least one multi-path scheduler set for the at least one service, or a bytecode or an executable binary pluggable into the at least one multi-path scheduler set for the at least one service; when the code is received, the step of compiling the code; and the step of storing the at least one multi-path scheduler set for the at least one service together with identification information of the corresponding service.

[0016] According to an embodiment, the step of determining a multi-path scheduler that can be provided to the terminal may include the steps of: establishing a multi-path (MA: multi access) PDU (protocol data unit) session with the terminal; determining, based on at least one of whether the multi-path scheduler is supportable in a performance measurement function (PMF) of the terminal, whether the multi-path scheduler is supportable in a PMF of the core network entity, or whether the multi-path scheduler corresponds to a service that can be supported for the terminal, from among the at least one multi-path scheduler set for the at least one service, the at least one multi-path scheduler that can be provided to the terminal; and storing the determined at least one multi-path scheduler as a list of multi-path schedulers applicable to the MA PDU session.

[0017] According to an embodiment, the step of transmitting an instance of the multi-path scheduler corresponding to the service requested by the terminal may further include the steps of: receiving, from the terminal, a message including identification information for the service requested by the terminal; and transmitting, to the terminal, information about the at least one multi-path scheduler that can be provided to the terminal, or information about the multi-path scheduler corresponding to the service requested by the terminal among the at least one multi-path scheduler that can be provided to the terminal.

[0018] According to an embodiment, the step of transmitting an instance of the multi-path scheduler corresponding to the service requested by the terminal may include a step of transmitting, to the terminal, a code operable by the multi-path scheduler corresponding to the service requested by the terminal, or a bytecode or an executable binary that can be plugged into the multi-path scheduler corresponding to the service requested by the terminal.

[0019] In addition, a method performed by a terminal of a communication system according to an embodiment of the present invention for achieving the above-described purpose may include: establishing a multi-path (MA: multi-access) PDU (protocol data unit) session with a core network entity; receiving an instance of a multi-path scheduler corresponding to a service requested by the terminal from the core network entity; and activating the multi-path scheduler corresponding to the service requested by the terminal.

[0020] According to an embodiment, the step of receiving an instance of the multi-path scheduler corresponding to the service requested by the terminal may further include: transmitting a message including identification information for the service requested by the terminal to the core network entity; receiving, from the core network entity, information about the at least one multi-path scheduler that can be provided to the terminal, or information about the multi-path scheduler corresponding to the service requested by the terminal among the at least one multi-path scheduler that can be provided to the terminal; and, when the information about the at least one multi-path scheduler that can be provided to the terminal is received, determining information about the multi-path scheduler corresponding to the service requested by the terminal among the at least one multi-path scheduler that can be provided to the terminal.

[0021] According to an embodiment, the step of receiving an instance of the multi-path scheduler corresponding to the service requested by the terminal may include the step of receiving, from the core network entity, a code operable by the multi-path scheduler corresponding to the service requested by the terminal, or a bytecode or an executable binary plug-inable to the multi-path scheduler corresponding to the service requested by the terminal; and, if the code is received, the step of compiling the code.

[0022] In addition, a core network entity of a communication system according to an embodiment of the present invention for achieving the above-described purpose may include a transceiver; and a control unit for receiving information on at least one multi-path scheduler set for at least one service from a data network entity providing the at least one service through the transceiver, determining at least one multi-path scheduler that can be provided to a terminal among the at least one multi-path scheduler set for the at least one service, transmitting an instance of the multi-path scheduler corresponding to a service requested by the terminal to the terminal through the transceiver, and activating the multi-path scheduler corresponding to the service requested by the terminal.

[0023] In addition, a terminal of a communication system according to an embodiment of the present invention for achieving the above-described purpose may include a transceiver; and a control unit for establishing a multi-path (MA: multi access) PDU (protocol data unit) session with a core network entity, receiving an instance of a multi-path scheduler corresponding to a service requested by the terminal from the core network entity through the transceiver, and activating the multi-path scheduler corresponding to the service requested by the terminal.

[0024] One embodiment of the present invention can provide a method for setting up a multi-path scheduler defined by a service in a terminal and a network and activating the same.

[0025] Additionally, one embodiment of the present invention can provide a scheduler that can dynamically distribute multiple service traffic on a packet basis through multiple paths.

[0026] In addition, one embodiment of the present invention can provide a method and device that can apply ATSS technology according to characteristics of packets or packet groups within a flow.

[0027] In addition, one embodiment of the present invention can provide a method and device for setting a multi-path scheduler capable of performing multi-path scheduling between flows.

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

[0029] FIG. 1 is a diagram showing an example configuration of a wireless communication system according to an embodiment of the present disclosure.

[0030] FIG. 2 is a diagram illustrating an example of an access traffic steering, switching, splitting (ATSS) support structure in a 3GPP 5G system according to an embodiment of the present invention.

[0031] FIG. 3 is a diagram schematically illustrating the configuration of an ATSSS-supporting terminal and UPF according to an embodiment of the present invention.

[0032] FIG. 4 is a drawing illustrating an example of an ATSSS structure according to an embodiment of the present invention.

[0033] Figure 5 illustrates workload-specific KPIs for each service and application.

[0034] FIG. 6 is a diagram illustrating an example of a method for setting and implementing a multi-path scheduler according to an embodiment of the present invention.

[0035] FIG. 7 is a diagram illustrating an example of a method for installing a multi-path scheduler in a terminal and a network according to an embodiment of the present invention.

[0036] FIG. 8 is a diagram illustrating an example of a method in which a multi-path scheduler is delivered to a CN according to an embodiment of the present invention.

[0037] FIG. 9 is a diagram illustrating an example of a method for adding a list of available multi-path schedulers for an MA PDU session according to an embodiment of the present invention.

[0038] FIG. 10 is a diagram illustrating an example of a method for checking the availability of a multi-path scheduler according to a service request according to an embodiment of the present invention.

[0039] FIG. 11 is a diagram illustrating another example of a method for checking the availability of a multi-path scheduler according to a service request according to an embodiment of the present invention.

[0040] FIG. 12 is a diagram illustrating an example of a method for activating a multi-path scheduler according to an embodiment of the present invention.

[0041] FIG. 13 is a diagram illustrating another example of a method for activating a multi-path scheduler according to an embodiment of the present invention.

[0042] FIG. 14 is a diagram illustrating an example of a method in which a multi-path scheduler according to an embodiment of the present invention is delivered to a CN in accordance with a 5G CN configuration.

[0043] FIG. 15 is a diagram illustrating an example of a method for adding a list of available multi-path schedulers for an MA PDU session according to an embodiment of the present invention, when following a 5G CN configuration.

[0044] FIG. 16 is a diagram illustrating an example of a method for executing a multi-path scheduler according to an embodiment of the present invention.

[0045] FIG. 17 is a block diagram illustrating the internal structure of a terminal according to an embodiment of the present invention.

[0046] Figure 18 is a block diagram showing the configuration of a base station according to one embodiment of the present invention.

[0047] FIG. 19 is a block diagram showing the configuration of a network entity according to one embodiment of the present invention.

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

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

[0050] The operating principles of the present invention are described in detail with reference to the attached diagram. The terms described below are defined based on their functions within the present invention. These terms may vary depending on the intent or custom of the user or operator, and therefore their definitions should be determined based on the overall content of this specification.

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

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

[0053] 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 storage medium that can direct a computer or other programmable data processing equipment to implement the function in a specific manner, so that the instructions stored in the computer-available or computer-readable storage medium 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).

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

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

[0056] Certain terms used in the following description are provided to aid in understanding the present disclosure, and the use of such specific terms may be changed to other forms without departing from the technical spirit of the present disclosure.

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

[0058] Hereinafter, the base station is an entity that performs resource allocation of a terminal, and may be at least one of a Node B, a BS (Base Station), an eNB (eNode B), a gNB (gNode B), a wireless access unit, a base station controller, or a node on a network. The terminal may include a UE (User Equipment), an MS (Mobile Station), a 5G UE, a cellular phone, a smartphone, a computer, or a multimedia system capable of performing a communication function. In addition, the embodiments of the present disclosure may be applied to other communication systems having a similar technical background or channel type to the embodiments of the present disclosure described below. In addition, the embodiments of the present disclosure may be applied to other communication systems with some modifications without significantly departing from the scope of the present disclosure at the discretion of a person having skilled technical knowledge. For example, the 5th generation mobile communication technology (5G, new radio, NR) developed after LTE-A may be included here, and the 5G below may also be a concept that includes existing LTE, LTE-A, and other similar services. In addition, the present disclosure may be applied to other communication systems with some modifications within a scope that does not significantly deviate from the scope of the present disclosure, as judged by a person having skilled technical knowledge.

[0059] In the following description, terms used to identify connection nodes, terms referring to network entities or network functions (NFs), terms referring to messages, terms referring to interfaces between network objects, 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.

[0060] For convenience of explanation below, some terms and names defined in the International Telecommunication Union (ITU) or the 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) standard and / or the 3GPP New Radio (NR) standard may be used. However, the present disclosure is not limited to the above terms and names, and can be equally applied to systems conforming to other standards.

[0061] Looking back at the evolution of wireless communication over successive generations, technologies have primarily been developed for human-facing services such as voice, multimedia, and data. With the commercialization of 5G (5th-generation) communication systems, an explosive increase in connected devices is expected to be connected to communication networks. Examples of networked objects include vehicles, robots, drones, home appliances, displays, smart sensors installed in various infrastructures, construction equipment, and factory equipment. Mobile devices are also expected to evolve into diverse form factors, such as augmented reality glasses, virtual reality headsets, and holographic devices. In the 6th-generation (6G) era, efforts are being made to develop improved 6G communication systems to connect hundreds of billions of devices and objects and provide diverse services. For this reason, 6G communication systems are often referred to as "Beyond 5G" systems.

[0062] The 6G communication system, expected to be realized around 2030, will have a maximum transmission speed of terabytes per second (1,000 gigabits per second) and a wireless latency of 100 microseconds (μsec). This means that compared to 5G, the transmission speed in a 6G communication system will be 50 times faster, while the wireless latency will be reduced to one-tenth.

[0063] To achieve these high data rates and ultra-low latency, 6G communication systems are being considered for implementation in the terahertz band (e.g., from 95 gigahertz (95 GHz) to 3 terahertz (3 THz)). Compared to the millimeter wave (mmWave) band introduced in 5G, the terahertz band is expected to experience more severe path loss and atmospheric absorption, making it more important to ensure signal reach, or coverage, in this band. Key technologies to ensure coverage include radio frequency (RF) components, antennas, new waveforms that offer better coverage than orthogonal frequency division multiplexing (OFDM), beamforming, and multiple antenna transmission technologies such as massive multiple-input and multiple-output (MIMO), full-dimensional MIMO (FD-MIMO), array antennas, and large-scale antennas. In addition, new technologies such as metamaterial-based lenses and antennas, high-dimensional spatial multiplexing using orbital angular momentum (OAM), and reconfigurable intelligent surfaces (RIS) are being discussed to improve the coverage of terahertz band signals.

[0064] In addition, in order to improve frequency efficiency and system network, 6G communication systems are developing full duplex technology that utilizes the same frequency resources for uplink and downlink at the same time; network technology that integrates satellites and high-altitude platform stations (HAPS); network structure innovation technology that supports mobile base stations and enables optimization and automation of network operation; dynamic spectrum sharing technology through collision avoidance based on spectrum usage prediction; AI-based communication technology that utilizes artificial intelligence (AI) from the design stage and internalizes end-to-end AI support functions to realize system optimization; and next-generation distributed computing technology that realizes services with complexity that exceeds the limits of terminal computing capabilities by utilizing ultra-high-performance communication and computing resources (mobile edge computing (MEC), cloud, etc.). In addition, efforts are being made to further strengthen connectivity between devices, further optimize networks, promote softwareization of network entities, and increase the openness of wireless communications through the design of new protocols to be used in 6G communication systems, the implementation of hardware-based security environments, the development of mechanisms for the safe use of data, and the development of technologies for maintaining privacy.

[0065] Research and development of these 6G communication systems are expected to enable a new level of hyper-connected experience through the hyper-connectivity of 6G communication systems, which encompass not only connections between things but also connections between people and things. Specifically, 6G communication systems are expected to enable services such as truly immersive extended reality (XR), high-fidelity mobile holograms, and digital replicas. Furthermore, services such as remote surgery, industrial automation, and emergency response, which are provided through 6G communication systems through enhanced security and reliability, will be applied in diverse fields such as industry, medicine, automobiles, and home appliances.

[0066] To satisfy the diverse services described above, mobile communication systems are proposing and developing technologies for traffic transmission through various types of access networks. Coordinated multi-point (CoMP) technology, proposed in 3GPP Rel-11 and 12 to support dual connectivity at Layer-2, and LTE-WLAN aggregation (LWA) and LTE-WLAN radio-level integration with IP security tunnel (LWIP), proposed in 3GPP Rel-13 and 14 for the purpose of integrated LTE and WLAN access transmission, have been standardized and are currently being utilized in commercial environments. Later, with the advent of 5G, a requirement arose for comprehensive technologies encompassing even non-3GPP access networks, and access traffic steering, switching, and splitting (ATSSS) technology was proposed in 3GPP Rel-16. Accordingly, the 5G system architecture inherently supports not only access networks that pass through multiple radio access technologies (RATs), but also non-3GPP accesses (such as Wi-Fi), and multi-access (MA) PDU (protocol data unit) sessions using these multi-accesses can be controlled / operated through a single common core network.

[0067] These technologies can be used in various ways, such as by leveraging multiple transmission paths across multiple access networks to achieve high transmission reliability, resistance to problems caused by network congestion and radio segment loss, and by distributing packets across multiple access networks to address network congestion and improve maximum bandwidth.

[0068] FIG. 1 is a diagram illustrating an example configuration of a wireless communication system according to an embodiment of the present disclosure. FIG. 1 illustrates the configuration of a 5G system.

[0069] Referring to FIG. 1, a 5G network may include at least one of the network entities (NE) or network functions (NF) described below.

[0070] (R)AN ((radio) access network) is an entity that performs radio resource allocation of a terminal, and may be at least one of an eNode B, a Node B, a BS (base station), an NG-RAN (next generation radio access network), a 5G-AN (5G access network), a 5G NR (5G new radio), a radio access unit, a base station controller, or a node on a network.

[0071] The terminal may include a UE (user equipment), an NG UE (next generation UE), an MS (mobile station), a cellular phone, a smartphone, a computer, an IoT (Internet of Things) device, or a multimedia system capable of performing a communication function.

[0072] Furthermore, while the embodiments of the present disclosure are described below using a 5G system as an example, the embodiments of the present disclosure can also be applied to other communication systems with similar technical backgrounds. Furthermore, the embodiments of the present disclosure can be applied to other communication systems with some modifications, as determined by a person skilled in the art, without significantly departing from the scope of the present disclosure.

[0073] As wireless communication systems evolve from 4G to 5G, a new core network (CN) called NG Core (next generation core) or 5GC (5G core network) is defined. This new core network virtualizes all existing network entities (NEs) into network functions (NFs). According to one embodiment of the present disclosure, a network function may refer to a network entity, a network component, or a network resource.

[0074] According to one embodiment of the present disclosure, 5GC may include NFs illustrated in FIG. 1. Of course, the present invention is not limited to the example illustrated in FIG. 1, and 5GC may include more or fewer NFs than the NFs illustrated in FIG. 1.

[0075] The Access and Mobility Management Function (AMF) may be a network function that manages the access and mobility of a terminal (UE). For example, AMF may perform network functions such as terminal registration, connection, reachability, mobility management, access verification, authentication, and mobility event generation.

[0076] A session management function (SMF) may be a network function that manages a packet data network (PDN) connection provided to a user equipment (UE). A PDN connection may be referred to as a protocol data unit (PDU) session. For example, an SMF may perform network functions such as session management through establishing, modifying, and releasing sessions, maintaining tunnels between a user plane function (UPF) and the RAN, selecting and controlling a user plane (UPF), controlling traffic processing in the UPF, and controlling the collection of charging data.

[0077] PCF (policy control function) may be a network function that applies the mobile carrier's service policy, charging policy, and policy for PDU sessions to terminals.

[0078] Unified Data Management (UDM) can be a network function that stores subscriber information. For example, UDM can perform functions such as generating authentication information for 3GPP security, processing user identifiers (User IDs), managing a list of network functions supporting UEs, and managing subscription information.

[0079] The network exposure function (NEF) may provide terminal information to servers outside the 5G network. Additionally, NEF may provide the information necessary for 5G network services and store it in a unified data repository (UDR).

[0080] The user plane function (UPF) may function as a gateway that transmits user data (PDU) to the data network (DN). More specifically, the UPF may process data so that it can transmit data transmitted by a terminal to an external network or transmit data received from an external network to the terminal. For example, the UPF may perform network functions such as serving as an anchor between radio access technologies (RATs), packet routing and forwarding, packet inspection, user plane policy enforcement, traffic usage report generation, and buffering.

[0081] NRF (network repository function) can store the profiles of NFs and perform the function of discovering NFs.

[0082] AUSF (authentication server function) can perform terminal authentication in 3GPP access networks and non-3GPP access networks.

[0083] NSSF (network slice selection function) can perform the function of selecting a network slice instance provided to a terminal.

[0084] The Network Data Analytics Function (NWDAF) collects data from multiple network functions (NFs) to ensure efficient operation of the 5GC network. This data is analyzed using a machine learning (ML) model, and the results are provided back to the NFs, helping them provide efficient network services.

[0085] An application function (AF) can communicate with a network operator to enable external servers (application servers) to utilize network services provided by the network operator. Depending on the deployment entity, AFs can be divided into internal AFs and external AFs. Internal AFs deployed by network operators can communicate directly with network functions (NFs) within the network operator. AFs deployed by third-party service providers (3rd-party service providers) must go through an NEF to communicate with NFs within the network operator.

[0086] DN (data network) can be a data network where terminals transmit and receive data to use network operator services or third-party services.

[0087] The terminal may include an IoT device. The IoT device may include a device that does not use battery power or operates with very little power, and such IoT devices are referred to as ambient IoT devices (or simply Ambient IoT).

[0088] In the 3GPP system, a conceptual link connecting NFs within a 5G system is defined as a reference point. The following illustrates a reference point included in the 5G system architecture depicted in Figure 1.

[0089] - N1: Reference point between UE and AMF

[0090] - N2: Reference point between (R)AN and AMF

[0091] - N3: Reference point between (R)AN and UPF

[0092] - N4: Reference point between SMF and UPF

[0093] - N5: Reference point between PCF and AF

[0094] - N6: Reference point between UPF and DN

[0095] - N7: Reference point between SMF and PCF

[0096] - N8: Reference point between UDM and AMF

[0097] - N9: Reference point between two core UPFs

[0098] - N10: Reference point between UDM and SMF

[0099] - N11: Reference point between AMF and SMF

[0100] - N12: Reference point between AMF and AUSF

[0101] - N13: Reference points between UDM and AUSF

[0102] - N14: Reference point between two AMFs

[0103] Additionally, in 3GPP systems, the 5G system architecture may include service-based interfaces such as the following examples:

[0104] - Nnssf: Service-based interface by NSSF

[0105] - Nnssaaf: Service-based interface by NSSAAF (network slice-specific authentication and authorization function)

[0106] - Nnef: Service-based interface by NEF

[0107] - Nausf: Service-based interface by AUSF

[0108] - Nnrf: Service-based interface by NRF

[0109] - Namf: Service-based interface by AMF

[0110] - Npcf: Service-based interface by PCF

[0111] - Nsmf: Service-based interface by SMF

[0112] - Nupf: Service-based interface by UPF

[0113] - Nudm: Service-based interface by UDM

[0114] - Naf: Service-based interface by AF

[0115] - Nasaf: Service-based interface by AUSF

[0116] - Neasdf: Service-based interface by EASDF (edge ​​application server discovery function)

[0117] - Nnwdaf: Service-based interface by NWDAF

[0118] The components included in the network structure of Fig. 1 may each represent a physical entity, or may represent software or hardware combined with software that performs an individual function. Reference symbols shown as Nx in the drawings, such as N1, N2, N3, ..., represent known interfaces between NFs in a 5G core network (CN), and since related descriptions may refer to standard specifications (TS 23.501, TS 23.502, TS 23.503, etc.), a detailed description will be omitted.

[0119] FIG. 2 is a diagram illustrating an example of an access traffic steering, switching, and splitting (ATSS) support structure in a 3GPP 5G system according to an embodiment of the present invention. FIG. 3 is a diagram schematically illustrating the configuration of an ATSSS-supporting terminal and UPF according to an embodiment of the present invention.

[0120] The ATSSS feature is a function that transmits data traffic through one or more accesses by utilizing both 3GPP access and / or non-3GPP access between the terminal and the 5G core network. A representative example is when the 5G core network determines that the user-plane resources between the terminal and the data network (DN) are insufficient or the network's resource management capacity is overloaded, rather than transmitting data traffic through only one of the accesses, activating both 5G access and Wi-Fi access to distribute the data transmission.

[0121] Referring to FIG. 2, a terminal (100) can access a mobile communication network, for example, a 3GPP access (Access) (210), and a network other than a mobile communication network, for example, a non-3GPP access (Non-3GPP Access) (220). The ATSSS function is composed of steering functionality and a steering mode. The steering functionality determines the transport protocol between the UPF of the transmitting device and the UPF of the receiving device. The steering functionality is determined by which transport layer determines the steering, switching, and splitting of traffic, and when the MPTCP (multi path TCP) (IETF RFC 8684) protocol located at a layer higher than the IP layer is used, it corresponds to 'MPTCP functionality (101)', and when it is determined at a layer lower than the IP layer, it corresponds to 'ATSSS-LL (ATSSS-lower layer) functionality (102)'. Terminals and networks supporting MPTCP functionality (11) can communicate with a separately configured MPTCP proxy within the UPF. MPTCP functionality can only control TCP traffic supporting the MPTCP protocol. If ATSSS-LL functionality is supported, the UPF does not include a separate proxy component and can control all types of TCP traffic. The steering mode defines how data traffic is steered, switched, and split.

[0122] Additionally, the UPF (110), SMF (130) and PCF (140) according to the present disclosure can perform separate control operations for connection of such terminal (100).

[0123] The UPF (110) according to the present disclosure may include an MPTCP proxy functionality (112) for allowing access from a 3GPP access point (210) as exemplified in FIG. 2, and may also include a performance measurement function (PMF) (111) for allowing access from a non-3GPP access point (220). The PMF (111) is a function for measuring a network environment between the terminal (100) and the UPF (110), and may perform round trip time (RTT) monitoring required for uplink and downlink, measuring whether 3GPP access and non-3GPP access are currently activated, access / link availability monitoring, etc. Based on the information provided by the PMF (111), the core network can determine the steering functionality and steering mode that can be supported, which may have an overall impact on parameter determination for N3 and N4 connections.

[0124] The ATSSS function described in FIG. 2 enables traffic transmission through multiple paths between a PDU (protocol data unit or packet data unit) session anchor UPF (110) and a terminal (100). The terminal (100) can request establishment of a multi-access (MA) PDU session. Meanwhile, in order to use ATSSS, the terminal (100), AMF (120), SMF (130), and UPF (110) must support ATSSS. The PCF (140) can provide an ATSSS policy to the terminal (100) and UPF (110) (via the SMF (130)).

[0125] Referring to FIG. 3, in the case of ATSSS technology, ATSSS proxies (310, 320) can be deployed in UPFs (ATSSS-enabled UPFs) (110) and terminals (ATSSS-enabled terminals) (100) for the purpose of distributing packets to multiple access networks. Each ATSSS proxy (310, 320) provides connectivity so that traffic received from a data network or terminal application can be transmitted in multiple paths through multiple accesses, and can be implemented in the form of a Multi-path TCP (MPTCP) proxy to support multi-path transmission of TCP connections, or in the form of a UDP-based Multi-path QUIC (MPQUIC) proxy to support even non-TCP connections. However, the scope of application of the technology covered in the present invention is not limited to a specific form or protocol with respect to the implementation form and multi-path protocol of the ATSSS proxy (310, 320).

[0126] The ATSSS proxy (310) operating in the UPF (110) can determine to which access network to forward traffic transmitted in the downlink for the MA PDU session. The ATSSS proxy (320) operating in the terminal (100) can determine to which access network to forward traffic transmitted in the uplink. When performing packet distribution between multiple paths in the existing ATSSS technology, the packet distribution method is dynamically determined according to the access and link conditions. Therefore, information such as access and link availability, delay time, and packet loss rate can be collected, and for this purpose, a performance measurement function (PMF) (315, 325) can be arranged together with the ATSSS proxy (310, 320) to collect the corresponding information.

[0127] FIG. 4 is a drawing illustrating an example of an ATSSS structure according to an embodiment of the present invention.

[0128] Although the above-described FIGS. 2 and 3 illustrate the use of 3GPP access and non-3GPP access in 5G, ATSSS can also be applied in environments utilizing 5G and 6G, as illustrated in FIG. 4. In this case, migration can occur between 5G access and 6G access.

[0129] And, according to an embodiment, a 5G RAN (5G DU / CU (410) and 5G RU (415)) providing 5G access may be connected to a terminal (5G-6G dual stack terminal) (100) capable of providing both 5G / 6G, and a 6G RAN (6G DU / CU (420) and 6G RU (425)) may be connected to a terminal (100) capable of providing both 5G / 6G. And, according to an embodiment, the 5G RAN (410, 415) and the 6G RAN (420, 425) may be connected to the same core network (CN) (150) capable of providing ATSSS. This is exemplary and the configuration of the present invention is not limited thereto, and at least one of the CNs of the 5G system may be configured separately for the 5G system, and at least one of the CNs of the 6G system may be configured separately for the 6G system.

[0130] Meanwhile, in the conventional technology represented by the current ATSSS standard, when transmitting traffic through a multi-path composed of multiple access networks, the traffic distribution method is defined in the form of a steering mode, and there is a process in which the terminal (100) and the network (e.g., UPF (110)) negotiate a supportable mode among the standard-defined steering modes, and traffic transmitted between the terminal (100) and the network can be distributed according to a method determined based on the result. An example of the specific method may be as follows.

[0131] ATSSS steering mode, which determines traffic distribution between multiple accesses based on the ATSSS standard, can have the following five types based on 3GPP rel-17.

[0132] - Active-standby: switching to standby access when active one is unavailable (default)

[0133] - Priority-based: a single access with highest priority but without congestion

[0134] - Smallest delay: a single access with shortest Round-Trip Time (RTT)

[0135] - Load balancing: multiple accesses using weight-based rate control

[0136] - Redundant: duplicate traffic if both accesses are available

[0137] The above ATSSS steering mode is provisioned in the form of a multi-access rule (MAR) (115) in the UPF (110) within the core network, and the rule can be applied to individual flow units according to the preceding packet detection rule (PDR) conditions. In addition, it can be provisioned to the terminal (100) in the form of an ATSSS rule that includes the ATSSS steering mode.

[0138] Furthermore, these packet distribution methods dynamically determine packet distribution methods for individual flows, at the smallest unit, based on access and link conditions. Therefore, information such as access and link availability, latency, and packet loss rates can be collected. For this purpose, a performance measurement function (PMF) can be deployed alongside the ATSSS proxy to collect this information.

[0139] Figure 5 illustrates workload-specific KPIs for each service and application.

[0140] In conventional ATSSS, steering mode can be applied on a flow-by-flow basis, but it is impossible to make such decisions on a packet-by-packet basis within a flow. This makes it impossible to apply a multi-path packet distribution mechanism that improves quality of experience (QoE).

[0141] In fact, as the transmission workloads required by recent user service applications diversify, key performance indicators (KPIs) that reflect various quality of service (QoS) conditions are required. Furthermore, heterogeneity exists in the multipath environment for multi-access, depending on the wireless resource and network provisioning conditions. For example, reliability (or loss ratio), throughput (with variance), peak throughput, and latency can be considered.

[0142] [Table 1] below provides an example of workload-specific KPIs for each target service and application.

[0143] Target service / appWorkloadKPISynthetic trafficLarge file downloadaggregate throughput, out-of-order ratioVideo traffic (short)short video clipinitial load timeVideo traffic (long)different video resolution (2K, 4K)buffer time / frequency during playbackWeb trafficHTTP( / 2) requestdownload time, page load timeflow completion time (FCT)UAVSensor data (real-time)Packet loss ratio

[0144] The contents of the above [Table 1] are provided as examples for convenience of explanation, and the present invention is not limited thereto.

[0145] For example, referring to (a) of Fig. 5 (packet duplication to overcome multi-path head-of-line blocking), let's look at the case of short video or web traffic where initial / page load time is an important KPI. In this case, the KPI can be improved by forwarding some packets corresponding to the early part of the traffic, rather than the entire flow, to the path with the minimum RTT regardless of the load of each access network. In this case, the flow-level packet distribution technology of existing technologies such as ATSSS has the problem that it is impossible to implement this mechanism. Therefore, it is impossible to reflect the case where scheduling decisions differ depending on the characteristics of packets (or packet groups) within the flow.

[0146] As another example, let's look at the case of a traffic service that requires higher reliability (re-injection of unacked packets to the fast path) with reference to Fig. 5 (b). In this case, at the TCP level, which requires minimizing the out-of-order ratio and packet loss ratio, packets for which no ACK has been received may need to be (re)transmitted on a packet-by-packet basis to another path. In this case, a multi-path scheduling policy must be dynamically applied to the packets being transmitted according to the transmission status for each service, but the existing ATSSS method has a problem in that it does not support this.

[0147] Conventional ATSSS technology only allows scheduling on an individual flow basis, and operates independently for each flow, regardless of the scheduling results of other flows. Therefore, if it's efficient to dynamically determine transmission paths based on service priority for multiple traffic transmitted from a single terminal, there's no way to apply this method. In other words, transmission scheduling between multiple flows is impossible.

[0148] For example, when multiple traffic streams have different QoE requirements, it's advantageous to route the most delay-critical traffic along the shortest RTT path (fast path). However, current ATSSS technology lacks a method for dynamically scheduling this traffic. Consequently, from an overall system operation perspective, there's no way to directly and efficiently schedule multiple services.

[0149] An object of one embodiment of the present invention is to provide a method for operating a multi-path scheduler defined by a service. More specifically, whereas existing methods only provide a multi-path packet distribution policy (e.g., steering policy in ATSSS rule) to the network and terminals, the present invention proposes a method for directly installing and activating a scheduler in the network and terminals within a communication system, so as to more directly dynamically distribute multiple service traffic on a packet-by-packet basis through multiple paths.

[0150] According to the above purpose, requirements for the invention composition proposed in the present invention may be as follows.

[0151] 1) Multi-path schedulers must be defined by the service (either predefined or dynamically defined).

[0152] 2) A multi-path scheduler must be applicable between flows defined by the service operating on each terminal.

[0153] 3) Each scheduler must be able to make the following decisions per flow, per specific packet, or per specific group of packets (e.g., HTTP request or frame-level).

[0154] a) Packet scheduling to a single path

[0155] b) Duplication of packet to multiple paths

[0156] c) Re-injection of retransmitted packet to different path

[0157] FIG. 6 is a diagram illustrating an example of a method for setting and implementing a multi-path scheduler according to an embodiment of the present invention.

[0158] Referring to FIG. 6, one embodiment of the present invention may include a method and device for installing and activating a service-defined multi-path scheduler in a network and terminal. First, the service-defined multi-path scheduler refers to an implementation that includes a scheduling algorithm that performs the following according to the KPI of a traffic service, and may operate in the following manner according to general requirements. The following is exemplary, and specific operations are not limited to the following.

[0159] A multi-path scheduler may refer to a device or implementation that receives input based on the status of a transport layer or a service layer, performs scheduling when a specific condition is satisfied, and provides the result.

[0160] - Input (610): Input required for scheduler operation, such as a metric (transport level metric) (RTT, loss ratio, transmission speed, cwnd, Tput, etc.) in the transport layer of traffic or a metric (service level metric) (buffer level, number of requests, etc.) in the service layer can be provided as input.

[0161] - Condition (620): Transmission-related event conditions occurring at the packet or flow level can be considered as conditions. For example, the arrival of a packet or a group of packets, detection of a packet drop, retransmission, etc. can be considered as conditions.

[0162] - Output (630): Scheduling results can be derived, such as which path among multiple paths to transmit a packet through, or copying (replicating) a packet to multiple paths and transmitting it simultaneously, transmitting traffic already transmitted through one path through another path, or transmitting a retransmitted packet through a path different from the path through which it was previously transmitted.

[0163] FIG. 7 is a diagram illustrating an example of a method for installing a multi-path scheduler in a terminal and a network according to an embodiment of the present invention.

[0164] Referring to FIG. 7, a service may be initiated in a data network (DN) (180) at step 700. The DN (180) is a data network of a network operator providing a service, and may be a data network through which a terminal (100) transmits and receives data in order to receive the service, and may include a server of the network operator, etc.

[0165] At step 710, the DN (180) can transfer (send) a multi-path scheduler to the CN (150) by a server-side application service (multi-path scheduler instantiation). The CN (150) may be any one of UPF (110), PCF (140), SMF (130), AMF (120), UDR (160), a base station, etc., but is not limited thereto, and any network entity capable of setting a multi-path scheduler and performing multi-path scheduling may correspond thereto.

[0166] At step 715, the terminal (100) may request the CN (150) to establish a multi-access (MA) PDU session. Accordingly, an MA PDU session may be established between the terminal (100) and the CN (150). A detailed description of this operation will be omitted.

[0167] At step 720, the CN (150) can add a list of multi-path schedulers available for the MA PDU session created by the terminal (100). Since the available services for each terminal (100) can be preset, the CN (150) can select a multi-path scheduler for a service available for the corresponding terminal (100) as an available multi-path scheduler for the corresponding MA PDU session.

[0168] At step 725, the terminal (100) can initiate a service. That is, the terminal (100) can initiate a data transmission and reception procedure for a specific service.

[0169] At step 730, the terminal (100) and the CN (150) can check the availability of the multi-path scheduler (according to the request of the service application) according to the requested service.

[0170] In step 740, among the multi-path schedulers transmitted from the DN (180) to the CN (150) in step 710, an available multi-path scheduler can be activated in the terminal (100) and the CN (150) for the corresponding MA PDU session.

[0171] Below, we will look at the specific actions of each of the above actions.

[0172] FIG. 8 is a diagram illustrating an example of a method in which a multi-path scheduler is delivered to a CN according to an embodiment of the present invention.

[0173] Referring to FIG. 8, at step 810, a service application operating on the server side, i.e., DN (180), can be executed and activated.

[0174] At step 820, DN (180) can instantiate the required multi-path scheduler according to service requirements. Then, DN (180) can transfer (transfer) at least one multi-path scheduler instance to CN (150).

[0175] According to an embodiment, at step 820, DN (180) may transmit code capable of operating as a multi-path scheduler to CN (150). Then, CN (150) may compile and activate the corresponding multi-path scheduler instance at step 830.

[0176] Alternatively, depending on the embodiment, at step 820, the DN (180) may directly transmit pluggable bytecode (e.g., extended Berkeley packet filter (eBPF)) or executable binary to the multi-path scheduler to the CN (150). Then, the CN (150) may activate the multi-path scheduler based on the received information.

[0177] At step 840, the CN (150) may store the corresponding multi-path scheduler. In this case, the multi-path scheduler may be mapped to an identifier for a service and stored in the CN (150). In this case, the service identifier may be mapped to the multi-path scheduler for each service in the form of a service ID (identity). The service ID may be a unique identifier for each service. Depending on the embodiment, the service ID may be derived by applying a hash function to a domain name, for example.

[0178] FIG. 9 is a diagram illustrating an example of a method for adding a list of available multi-path schedulers for an MA PDU session according to an embodiment of the present invention.

[0179] Referring to FIG. 9, an MA PDU session can be established (created) between a terminal (100) and a CN (150) at step 910.

[0180] And at step 920, negotiation can be performed on a list of input metrics supported by the PMF set (or deployed) in the terminal (100) and the CN (150). The monitoring information supported by the PMF of the terminal (100) and the monitoring information supported by the PMF of the CN (150) may be different. Accordingly, the terminal (100) and the CN (150) can perform negotiation on a list of input metrics that can be monitored, so that a multi-path scheduler that can apply an input metric that both entities can support can be selected. Alternatively, a multi-path scheduler that can support an input metric that the terminal (100) can support can be selected.

[0181] Meanwhile, since the available services for each terminal (100) can be preset, the CN (150) can select at least one multi-path scheduler for the available services for the corresponding terminal (100) as the available multi-path scheduler for the corresponding MA PDU session.

[0182] According to an embodiment, a policy for selecting a multi-path scheduler may be set according to the charging and management policy (policy and charging rule) for each terminal user set by the operator. According to an embodiment, the policy may be set by the PCF. Information on services available to the user (terminal (100)) may be stored in the server as user information, such as the UDR of the CN (150), and may be provided to determine the policy according to a request from the PCF, UPF, etc.

[0183] In some embodiments, when the above policy is set, at least one available multi-path scheduler for the corresponding MA PDU session may be selected by the PCF. Alternatively, in some embodiments, the policy may be provided from the PCF to another network entity, for example, the UPF, and the UPF may select an available multi-path scheduler for the corresponding MA PDU session according to the policy.

[0184] At step 930, the CN (150) can check whether the input metric requirement is satisfied for each multi-path scheduler and determine a supportable multi-path scheduler. Then, the list of the determined multi-path schedulers can be stored for the corresponding MA PDU session. According to an embodiment, the list of multi-path schedulers can be stored within the context of the corresponding MA PDU session. According to an embodiment, the list of multi-path schedulers can be stored in the UDR.

[0185] FIG. 10 is a diagram illustrating an example of a method for checking the availability of a multi-path scheduler according to a service request according to an embodiment of the present invention.

[0186] Referring to FIG. 10, a service can be executed and activated in a terminal (100) at step 1010.

[0187] At step 1020, the terminal (100) can request multi-path scheduler information by sending a request message including a service identifier (service ID) to the CN (150).

[0188] Accordingly, the CN (150) can identify at least one multi-path scheduler corresponding to the service ID. According to an embodiment, the PCF of the CN (150) can request information on available multi-path schedulers by transmitting the service ID to the UDR and receive information on the multi-path scheduler corresponding to the service ID from the UDR. The information on the multi-path scheduler can be provided in the form of a list for at least one multi-path scheduler.

[0189] At step 1030, the CN (150) may determine a multi-path scheduler to use among at least one multi-path scheduler corresponding to the service ID. Depending on the embodiment, the CN (150) may determine the multi-path scheduler to use by considering the characteristics of functions and / or services that can be supported by the terminal (100) and / or the PMF within the CN (150) (MW).

[0190] And CN (150) can transmit information of the selected multi-path scheduler to the terminal (100).

[0191] FIG. 11 is a diagram illustrating another example of a method for checking the availability of a multi-path scheduler according to a service request according to an embodiment of the present invention.

[0192] Referring to FIG. 11, a service can be executed and activated in a terminal (100) at step 1110.

[0193] At step 1120, the terminal (100) can request multi-path scheduler information by sending a request message including a service identifier (service ID) to the CN (150).

[0194] Accordingly, the CN (150) can identify at least one multi-path scheduler corresponding to the service ID. According to an embodiment, the PCF of the CN (150) can request information on available multi-path schedulers by transmitting the service ID to the UDR and receive information on the multi-path scheduler corresponding to the service ID from the UDR. The information on the multi-path scheduler can be provided in the form of a list for at least one multi-path scheduler.

[0195] At step 1130, the CN (150) can transmit information about at least one multi-path scheduler corresponding to the service ID to the terminal (100).

[0196] And the terminal (100) can determine the multi-path scheduler to be used among at least one multi-path scheduler corresponding to the service ID. According to an embodiment, the terminal (100) can determine the multi-path scheduler to be used by considering the characteristics of functions and / or services that can be supported by the PMF within the terminal (100) and / or the CN (150) (MW).

[0197] In the embodiment illustrated in Fig. 10, the decision of the multi-path scheduler is made by the CN (150) and notified to the terminal (100). In addition, in the embodiment illustrated in Fig. 11, the decision of the multi-path scheduler is made by the terminal (100) by receiving information of the multi-path scheduler from the CN (150).

[0198] FIG. 12 is a diagram illustrating an example of a method for activating a multi-path scheduler according to an embodiment of the present invention.

[0199] Referring to FIG. 12, at step 1220, the CN (150) can transmit a multi-path scheduler instance to the terminal (100).

[0200] According to an embodiment, the CN (150) may compile and activate a code operable as a scheduler in step 1210, and transmit a multi-path scheduler instance to the terminal (100) in step 1220.

[0201] Alternatively, depending on the embodiment, the CN (150) may directly transmit to the terminal (100) a bytecode (e.g., eBPF) or an executable binary that can be plugged into the multi-path scheduler. The terminal (100) may then activate the multi-path scheduler based on the received information.

[0202] And at step 1230, the terminal (100) and CN (150) can execute and initialize the PMF to receive information (e.g., input metric) required for the multi-path scheduler.

[0203] At step 1240, the terminal (100) and CN (150) can run a multi-path scheduler to apply it to the MA PDU session.

[0204] FIG. 13 is a diagram illustrating another example of a method for activating a multi-path scheduler according to an embodiment of the present invention.

[0205] Referring to FIG. 13, at step 1310, the terminal (100) may transmit a message requesting the CN (100) to transmit the determined multi-path scheduler instance. At this time, the message may include information about the determined multi-path scheduler.

[0206] At step 1320, the CN (150) can transmit the requested multi-path scheduler instance to the terminal (100).

[0207] According to an embodiment, the CN (150) may transmit a code capable of operating as a multi-path scheduler to the terminal (100). Then, the terminal (100) may compile and activate the corresponding multi-path scheduler instance at step 1330.

[0208] Alternatively, depending on the embodiment, the CN (150) may directly transmit to the terminal (100) a bytecode (e.g., eBPF) or an executable binary that can be plugged into the multi-path scheduler. The terminal (100) may then activate the multi-path scheduler based on the received information.

[0209] And at step 1340, the terminal (100) and CN (150) can execute and initialize the PMF to receive information (e.g., input metric) required for the multi-path scheduler.

[0210] At step 1350, the terminal (100) and CN (150) can run a multi-path scheduler to apply it to the MA PDU session.

[0211] In the embodiment illustrated in FIG. 12, the activation of the corresponding MA PDU session of the multi-path scheduler is initiated by the CN (150), and in the embodiment illustrated in FIG. 13, the activation of the corresponding MA PDU session of the multi-path scheduler is initiated by the terminal (100).

[0212] FIG. 14 is a diagram illustrating an example of a method in which a multi-path scheduler according to an embodiment of the present invention is delivered to a CN in accordance with a 5G CN configuration.

[0213] Figure 14 illustrates an exemplary method for following the 5G CN configuration, according to the method described in Figure 8, in which a multi-path scheduler is delivered to a CN. Accordingly, the network entities illustrated in Figure 14 are merely exemplary and may be replaced by any network entity that performs similar operations.

[0214] Referring to FIG. 14, at step 1410, DN (180) may transmit a message requesting the transfer of a multi-path scheduler to AF (application function) (170). The message requesting the transfer of the multi-path scheduler may include information about at least one multi-path scheduler to be transferred, for example, at least one multi-path scheduler instance.

[0215] At step 1420, AF (170) may transmit a response message (which may include “200 OK”) to DN (180) regarding the forwarding of the multi-path scheduler in response to the forwarding request of the multi-path scheduler.

[0216] At step 1430, AF (170) may transmit a message requesting scheduler storage to UDR (160). The message requesting scheduler storage may include information on at least one multi-path scheduler instance, and, depending on the embodiment, may further include service ID information corresponding to each of the at least one multi-path scheduler instances.

[0217] At step 1440, the UDR (160) may store at least one multi-path scheduler instance and transmit a response message (which may include “200 OK”) for storing the scheduler to the AF (170).

[0218] FIG. 15 is a diagram illustrating an example of a method for adding a list of available multi-path schedulers for an MA PDU session according to an embodiment of the present invention, when following a 5G CN configuration.

[0219] FIG. 15 illustrates an exemplary method for following a 5G CN configuration, according to the embodiment described in FIG. 9, in which a list of available multi-path schedulers for MA PDU sessions is added. Accordingly, the network entities illustrated in FIG. 15 are exemplary and any network entity performing similar operations may be substituted.

[0220] Referring to FIG. 15, an MA PDU session may be established (created) between a terminal (100) and a CN (150) at step 1510. At this time, the CN (150) may include, as illustrated, an AMF (120), an SMF (130), a PCF (140), etc., and may further include network entities, such as a UPF (110), although not illustrated.

[0221] At step 1520, the terminal (100) (or the PMF of the terminal (100)) can transmit information about input metrics that the PMF of the terminal (100) can support (monitor) to the SMF (130) (via the AMF (120)).

[0222] At step 1530, the SMF (130) may transmit a message requesting the PCF (140) to select a multi-path scheduler that can be supported. At this time, the request message may include information regarding input metrics that the PMF of the terminal (100) can support, received from the terminal (100).

[0223] At step 1540, the PCF (140) may request information about at least one multi-path scheduler from the UDR (160) (retrieve request) and receive information about at least one multi-path scheduler from the UDR (160) (retrieve response). The information about the at least one multi-path scheduler may be provided to the PCF (140) in the form of a list of at least one multi-path scheduler.

[0224] At step 1550, the PCF (140) can select a supportable multi-path scheduler from among at least one multi-path scheduler received from the UDR (160). The PCF (140) can select a supportable multi-path scheduler by considering whether at least one multi-path scheduler received from the UDR (160) can support an input metric that the PMF of the terminal (100) can support, and whether the terminal (100) is compatible with the multi-path scheduler for a service available to it.

[0225] At step 1560, the PCF (140) can transmit (notify) information about at least one multi-path scheduler selected at step 1550 to the UDR (160). The UDR (160) can store information about at least one multi-path scheduler applicable to the corresponding MA PDU session based on the information received from the PCF (140). In addition, the information stored in the UDR (160) can be used in the future when there is a request for activation of the multi-path scheduler, etc.

[0226] FIG. 16 is a diagram illustrating an example of a method for executing a multi-path scheduler according to an embodiment of the present invention.

[0227] Figure 16 illustrates an exemplary method for executing a multi-path scheduler according to a 5G CN configuration. Therefore, the network entity illustrated in Figure 16 is merely an example, and any network entity performing similar operations may be substituted.

[0228] Referring to FIG. 16, at step 1610, the SMF (130) may request the UDR (160) to search for a multi-path scheduler. According to an embodiment, the message requesting the search for a multi-path scheduler may include information for identifying the requesting multi-path scheduler, such as an identifier. In addition, the request message may further include identification information for the established MA PDU session.

[0229] At step 1620, UDR (160) may transmit an instance for the requested multi-path scheduler to SMF (130).

[0230] At step 1630, SMF (130) may transmit at least one multi-path scheduler instance received from UDR (160) to UPF (110).

[0231] According to an embodiment, at step 1630, the SMF (130) may transmit code capable of operating as a multi-path scheduler to the UPF (110). Then, the UPF (110) may compile the corresponding multi-path scheduler instance at step 1640 and activate and execute it at step 1650.

[0232] Alternatively, depending on the embodiment, at step 1630, the SMF (130) may directly pass pluggable bytecode (e.g., eBPF) or executable binary to the UPF (110) for the multi-path scheduler. Then, the UPF (110) may activate and execute the multi-path scheduler based on the information received at step 1650.

[0233] At step 1660, a connection can be established between the PMF (111) of the UPF (110) and the UPF (110).

[0234] At step 1670, the UPF (100) may request the PMF (111) of the UPF (100) to pass input information to at least one activated multi-path scheduler.

[0235] And at step 1680, the PMF (111) can transmit input information to at least one multi-path scheduler activated in the UPF (100). Depending on the embodiment, the transmission of the input information may be performed periodically, or may be performed when a preset condition is satisfied, or may be performed aperiodically.

[0236] The interface between NFs other than the interface between UPF (110) and SMF (130) may be a 5G standardized SBI (service-based interface) using HTTP (hypertext transfer protocol) REST API (representational state transfer application program interface) or another custom IPC (inter-process communication) interface.

[0237] The N4 interface between UPF (110) and SMF (130) can be implemented using PFCP (packet forwarding control protocol) of a 5G network or HTTP REST API of a next-generation network.

[0238] Meanwhile, in the embodiment of FIG. 16, a method for activating and executing a multi-path scheduler in UPF (110) is exemplarily described, and this method can be similarly applied to a method for activating and executing a multi-path scheduler in a terminal (100).

[0239] For example, the PMF of the terminal (100) may be activated so that the terminal (100) may request the PMF of the terminal (100) to transmit input information to at least one multi-path scheduler activated in the terminal (100). And the PMF of the terminal (100) may transmit the input information to the at least one multi-path scheduler activated in the terminal (100) periodically or aperiodically or according to preset conditions.

[0240] FIG. 17 is a block diagram illustrating the internal structure of a terminal according to an embodiment of the present invention.

[0241] Referring to FIG. 17, the terminal includes an RF (Radio Frequency) processing unit (1710), a baseband processing unit (1720), a storage unit (1730), and a control unit (1740).

[0242] The RF processing unit (1710) performs functions for transmitting and receiving signals through a wireless channel, such as signal band conversion and amplification. That is, the RF processing unit (1710) up-converts the baseband signal provided from the baseband processing unit (1720) into an RF band signal and transmits it through an antenna, and down-converts the RF band signal received through the antenna into a baseband signal. For example, the RF processing unit (1710) may include a transmission filter, a reception filter, an amplifier, a mixer, an oscillator, a digital to analog convertor (DAC), an analog to digital convertor (ADC), etc. In the drawing, only one antenna is illustrated, but the terminal may be equipped with multiple antennas. In addition, the RF processing unit (1710) may include multiple RF chains. Furthermore, the RF processing unit (1710) may perform beamforming. For the above beamforming, the RF processing unit (1710) can adjust the phase and size of each signal transmitted and received through multiple antennas or antenna elements. In addition, the RF processing unit can perform MIMO and receive multiple layers when performing the MIMO operation.

[0243] The baseband processing unit (1720) performs a conversion function between a baseband signal and a bit stream according to the physical layer specifications of the system. For example, when transmitting data, the baseband processing unit (1720) generates complex symbols by encoding and modulating a transmission bit stream. In addition, when receiving data, the baseband processing unit (1720) restores the reception bit stream by demodulating and decoding the baseband signal provided from the RF processing unit (1710). For example, in the case of an orthogonal frequency division multiplexing (OFDM) method, when transmitting data, the baseband processing unit (1720) generates complex symbols by encoding and modulating a transmission bit stream, maps the complex symbols to subcarriers, and then configures OFDM symbols by performing an inverse fast Fourier transform (IFFT) operation and inserting a cyclic prefix (CP). In addition, when receiving data, the baseband processing unit (1720) divides the baseband signal provided from the RF processing unit (1710) into OFDM symbol units, restores signals mapped to subcarriers through FFT (fast Fourier transform), and then restores the received bit string through demodulation and decoding.

[0244] The baseband processing unit (1720) and the RF processing unit (1710) transmit and receive signals as described above. Accordingly, the baseband processing unit (1720) and the RF processing unit (1710) may be referred to as a transmitter, a receiver, a transceiver, or a communication unit. Furthermore, at least one of the baseband processing unit (1720) and the RF processing unit (1710) may include a plurality of communication modules to support a plurality of different wireless access technologies. In addition, at least one of the baseband processing unit (1720) and the RF processing unit (1710) may include different communication modules to process signals of different frequency bands. For example, the different wireless access technologies may include a wireless LAN (e.g., IEEE 802.11), a cellular network (e.g., LTE), etc. Additionally, the different frequency bands may include a super high frequency (SHF) (e.g., 2.NRHz, NRhz) band and a millimeter wave (mm wave) (e.g., 60GHz) band.

[0245] The storage unit (1730) stores data such as basic programs, application programs, and setting information for the operation of the terminal. In particular, the storage unit (1730) can store information related to a second access node that performs wireless communication using a second wireless access technology. In addition, the storage unit (1730) provides the stored data at the request of the control unit (1740).

[0246] The control unit (1740) controls the overall operations of the terminal. For example, the control unit (1740) transmits and receives signals through the baseband processing unit (1720) and the RF processing unit (1710). In addition, the control unit (1740) records and reads data in the storage unit (1740). For this purpose, the control unit (1740) may include at least one processor. For example, the control unit (1740) may include a communication processor (CP) that performs control for communication and an application processor (AP) that controls upper layers such as application programs.

[0247] Figure 18 is a block diagram showing the configuration of a base station according to one embodiment of the present invention.

[0248] Referring to FIG. 18, the base station is configured to include an RF processing unit (1810), a baseband processing unit (1820), a backhaul communication unit (1830), a storage unit (1840), and a control unit (1850).

[0249] The RF processing unit (1810) performs functions for transmitting and receiving signals through a wireless channel, such as signal band conversion and amplification. That is, the RF processing unit (1810) up-converts the baseband signal provided from the baseband processing unit (1820) into an RF band signal and transmits it through an antenna, and down-converts the RF band signal received through the antenna into a baseband signal. For example, the RF processing unit (1810) may include a transmission filter, a reception filter, an amplifier, a mixer, an oscillator, a DAC, an ADC, etc. In the drawing, only one antenna is illustrated, but the first access node may have multiple antennas. In addition, the RF processing unit (1810) may include multiple RF chains. Furthermore, the RF processing unit (1810) may perform beamforming. For the above beamforming, the RF processing unit (1810) can adjust the phase and size of each signal transmitted and received through multiple antennas or antenna elements. The RF processing unit can perform a downlink MIMO operation by transmitting one or more layers.

[0250] The baseband processing unit (1820) performs a conversion function between a baseband signal and a bit stream according to the physical layer specifications of the first wireless access technology. For example, when transmitting data, the baseband processing unit (1820) generates complex symbols by encoding and modulating a transmission bit stream. In addition, when receiving data, the baseband processing unit (1820) restores the reception bit stream by demodulating and decoding the baseband signal provided from the RF processing unit (1810). For example, in the case of OFDM, when transmitting data, the baseband processing unit (1820) generates complex symbols by encoding and modulating a transmission bit stream, maps the complex symbols to subcarriers, and then configures OFDM symbols through IFFT operation and CP insertion. In addition, when receiving data, the baseband processing unit (1820) divides the baseband signal provided from the RF processing unit (1810) into OFDM symbol units, restores the signals mapped to subcarriers through FFT operation, and then restores the received bit string through demodulation and decoding. The baseband processing unit (1820) and the RF processing unit (1810) transmit and receive signals as described above. Accordingly, the baseband processing unit (1820) and the RF processing unit (1810) may be referred to as a transmitter, a receiver, a transceiver, a communication unit, or a wireless communication unit.

[0251] The backhaul communication unit (1830) provides an interface for communicating with other nodes within the network. That is, the backhaul communication unit (1830) converts a bit string transmitted from the base station to another node, such as an auxiliary base station or core network, into a physical signal, and converts a physical signal received from the other node into a bit string.

[0252] The storage unit (1840) stores data such as basic programs, application programs, and configuration information for the operation of the base station. In particular, the storage unit (1840) can store information on bearers assigned to connected terminals, measurement results reported from connected terminals, and the like. In addition, the storage unit (1840) can store information that serves as a basis for determining whether to provide or terminate multiple connections to a terminal. In addition, the storage unit (1840) provides the stored data at the request of the control unit (1850).

[0253] The control unit (1850) controls the overall operations of the base station. For example, the control unit (1850) transmits and receives signals through the baseband processing unit (1820) and the RF processing unit (1810) or through the backhaul communication unit (1830). In addition, the control unit (1850) records and reads data in the storage unit (1840). For this purpose, the control unit (1850) may include at least one processor.

[0254] FIG. 19 is a block diagram showing the configuration of a network entity according to one embodiment of the present invention.

[0255] Referring to FIG. 19, a network entity according to an embodiment of the present invention may include a processor (control unit) (1920) that controls the overall operation of the network entity, a transceiver unit (1910) including a transmitter and a receiver, and a storage unit (memory) (1930). Of course, the present invention is not limited to the above example, and the network entity may include more or fewer components than those illustrated in FIG. 19.

[0256] According to one embodiment of the present disclosure, the transceiver (1910) can transmit and receive signals with at least one of other network entities or terminals. The signals transmitted and received with at least one of the other network entities or terminals may include control information and data.

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

[0258] According to one embodiment of the present disclosure, the storage unit (1930) can store data such as basic programs, application programs, and setting information for the operation of the network entity. In particular, the storage unit (1930) provides the stored data upon request of the control unit (1920). The storage unit (1930) can be configured as a storage medium or a combination of storage media such as a ROM, a RAM, a hard disk, a CD-ROM, and a DVD. In addition, the storage unit (1930) can be multiple. In addition, the control unit (1920) can perform the above-described embodiments of the present disclosure based on a program for performing the above-described embodiments stored in the storage unit (1930).

[0259] The above network entity may be any one of CN, DN, AMF, SMF, UPF, PCF, UDM, UDR, NEF, NRF, AF, NSSF, NWDAF, NSACF, AUSF, EASDF, NSSAAF, etc.

[0260] It should be noted that the configuration diagrams, exemplary diagrams of control / data signal transmission methods, exemplary diagrams of operating procedures, and configuration diagrams illustrated in the above FIGS. 1 to 19 are not intended to limit the scope of the present disclosure. That is, not all components, entities, or operational steps described in the above FIGS. 1 to 19 should be construed as essential components for carrying out the disclosure, and the disclosure may be implemented without detriment to its essence even if only some components are included.

[0261] The operations of the network entity or terminal described above can be realized by providing a memory device storing the corresponding program code within any component of the network entity or terminal device. That is, the control unit of the network entity or terminal device can execute the operations described above by reading and executing the program code stored in the memory device using a processor or CPU (Central Processing Unit).

[0262] The various components and modules of the network entity, base station or terminal device described in this specification may be operated using hardware circuits, such as logic circuits based on complementary metal oxide semiconductors, firmware, software and / or hardware and firmware and / or software embedded in a machine-readable medium. For example, various electrical structures and methods may be implemented using electrical circuits such as transistors, logic gates and application-specific semiconductors.

[0263] While the detailed description of this disclosure has described specific embodiments, it should be understood that various modifications are possible without departing from the scope of this disclosure. Therefore, the scope of this disclosure should not be limited to the described embodiments, but should be defined not only by the scope of the claims described below, but also by equivalents thereof.

Claims

1. In a method performed by a core network entity of a communication system, A step of receiving information of at least one multi-path scheduler set for at least one service from a data network entity providing the at least one service; A step of determining at least one multi-path scheduler that can be provided to a terminal among the at least one multi-path scheduler set for the at least one service; A step of transmitting an instance of a multi-path scheduler corresponding to a service requested by the terminal to the terminal; and A method comprising the step of activating the multi-path scheduler corresponding to the service requested by the terminal.

2. In paragraph 1, A method characterized in that the at least one multi-path scheduler determines a path on which transmission and reception are to be performed according to at least one of flow-by-flow, packet-by-packet, or packet-by-packet group, and distributes the flow, packet, or packet group to the determined path.

3. In the first paragraph, the step of receiving information of the at least one multi-path scheduler set for the at least one service is, A step of receiving, from the data network, a code operable with the at least one multi-path scheduler configured for the at least one service, or a bytecode or an executable binary plug-inable to the at least one multi-path scheduler configured for the at least one service; When the above code is received, a step of compiling the code; and A method characterized by comprising the step of storing the at least one multi-path scheduler set for the at least one service together with identification information of the corresponding service.

4. In the first paragraph, the step of determining a multi-path scheduler that can be provided to the terminal is as follows: A step of establishing a multi-path (MA: multi access) PDU (protocol data unit) session with the above terminal; A step of determining at least one multi-path scheduler that can be provided to the terminal among the at least one multi-path scheduler set for the at least one service based on at least one of whether the terminal's PMF (performance measurement function) can support the terminal, whether the core network entity's PMF can support the terminal, or whether the multi-path scheduler corresponds to a service that can be supported for the terminal; and A method characterized by comprising the step of storing the determined at least one multi-path scheduler as a list of multi-path schedulers applicable to the MA PDU session.

5. In the first paragraph, the step of transmitting an instance of the multi-path scheduler corresponding to the service requested by the terminal is as follows: A step of receiving a message from the terminal including identification information for the service requested by the terminal; and A method characterized by further comprising a step of transmitting to the terminal information about at least one multi-path scheduler that can be provided to the terminal, or information about a multi-path scheduler that corresponds to a service requested by the terminal among the at least one multi-path scheduler that can be provided to the terminal.

6. In the first paragraph, the step of transmitting an instance of the multi-path scheduler corresponding to the service requested by the terminal is as follows: A method characterized by comprising a step of transmitting to the terminal a code operable by the multi-path scheduler corresponding to the service requested by the terminal, or a bytecode or an executable binary that can be plugged into the multi-path scheduler corresponding to the service requested by the terminal.

7. In a method performed by a terminal of a communication system, A step of establishing a core network entity and a multi-path (MA: multi access) PDU (protocol data unit) session; A step of receiving an instance of a multi-path scheduler corresponding to a service requested by the terminal from the core network entity; and A method comprising the step of activating the multi-path scheduler corresponding to the service requested by the terminal.

8. In paragraph 7, A method characterized in that the at least one multi-path scheduler determines a path on which transmission and reception are to be performed according to at least one of flow-by-flow, packet-by-packet, or packet-by-packet group, and distributes the flow, packet, or packet group to the determined path.

9. In the 7th paragraph, the step of receiving an instance of the multi-path scheduler corresponding to the service requested by the terminal is as follows: A step of transmitting a message including identification information for the service requested by the terminal to the core network entity; A step of receiving, from the core network entity, information about at least one multi-path scheduler that can be provided to the terminal, or information about a multi-path scheduler that corresponds to a service requested by the terminal among the at least one multi-path scheduler that can be provided to the terminal; A method characterized in that, when information about at least one multi-path scheduler that can be provided to the terminal is received, the method further comprises a step of determining information about the multi-path scheduler corresponding to the service requested by the terminal among the at least one multi-path scheduler that can be provided to the terminal.

10. In the 7th paragraph, the step of receiving an instance of the multi-path scheduler corresponding to the service requested by the terminal is as follows: A step of receiving, from the core network entity, a code operable as the multi-path scheduler corresponding to the service requested by the terminal, or a bytecode or an executable binary that can be plugged into the multi-path scheduler corresponding to the service requested by the terminal; A method characterized by comprising the step of compiling the code when the code is received.

11. In the core network entity of the communication system, Transmitter and receiver; and A core network entity comprising a control unit that receives information about at least one multi-path scheduler set for at least one service from a data network entity providing the at least one service through the transceiver, determines at least one multi-path scheduler that can be provided to a terminal among the at least one multi-path scheduler set for the at least one service, transmits an instance of the multi-path scheduler corresponding to a service requested by the terminal to the terminal through the transceiver, and activates the multi-path scheduler corresponding to the service requested by the terminal.

12. In paragraph 11, A core network entity characterized in that the at least one multi-path scheduler determines a path for performing transmission and reception according to at least one of flow-wise, packet-wise, or packet-group-wise, and distributes the flow, packet, or packet group to the determined path.

13. In the 11th paragraph, the control unit, A core network entity characterized in that it receives, from the data network through the transceiver, a code operable with the at least one multi-path scheduler set for the at least one service, or a bytecode or an executable binary pluggable into the at least one multi-path scheduler set for the at least one service, and, when the code is received, compiles the code and stores the at least one multi-path scheduler set for the at least one service together with identification information of the corresponding service.

14. In the 11th paragraph, the control unit, A core network entity characterized in that it establishes a multi-path (MA: multi-access) PDU (protocol data unit) session with the terminal, determines at least one multi-path scheduler that can be provided to the terminal among the at least one multi-path scheduler set for the at least one service based on at least one of whether the terminal can support a performance measurement function (PMF), whether the core network entity can support the at least one service, or whether the multi-path scheduler corresponds to a service that can be supported for the terminal, and stores the determined at least one multi-path scheduler as a list of multi-path schedulers applicable to the MA PDU session.

15. In the 11th paragraph, the control unit, A core network entity characterized in that it receives a message including identification information for the service requested by the terminal from the terminal through the transceiver, and transmits to the terminal through the transceiver information about the at least one multi-path scheduler that can be provided to the terminal, or information about the multi-path scheduler corresponding to the service requested by the terminal among the at least one multi-path scheduler that can be provided to the terminal.

16. In the 11th paragraph, the control unit, A core network entity characterized in that it transmits to the terminal, through the transceiver, a code operable by the multi-path scheduler corresponding to the service requested by the terminal, or a bytecode or an executable binary that can be plugged into the multi-path scheduler corresponding to the service requested by the terminal.

17. At the terminal of the communication system, Transmitter and receiver; and A terminal including a control unit that establishes a core network entity and a multi-path (MA: multi access) PDU (protocol data unit) session, receives an instance of a multi-path scheduler corresponding to a service requested by the terminal from the core network entity through the transceiver, and activates the multi-path scheduler corresponding to the service requested by the terminal.

18. In paragraph 17, A terminal characterized in that the at least one multi-path scheduler determines a path for performing transmission and reception according to at least one of flow-by-flow, packet-by-packet, or packet-by-packet group, and distributes the flow, packet, or packet group to the determined path.

19. In the 17th paragraph, the control unit, A terminal characterized in that it transmits a message including identification information for the service requested by the terminal to the core network entity through the transceiver, receives information about the at least one multi-path scheduler that can be provided to the terminal, or information about the multi-path scheduler corresponding to the service requested by the terminal among the at least one multi-path scheduler that can be provided to the terminal from the core network entity through the transceiver, and, when the information about the at least one multi-path scheduler that can be provided to the terminal is received, determines information about the multi-path scheduler corresponding to the service requested by the terminal among the at least one multi-path scheduler that can be provided to the terminal.

20. In the 17th paragraph, the control unit, A terminal characterized in that it receives, from the core network entity through the transceiver, a code operable by the multi-path scheduler corresponding to the service requested by the terminal, or a bytecode or an executable binary that can be plugged into the multi-path scheduler corresponding to the service requested by the terminal, and compiles the code when the code is received.

Images