Method and apparatus for guaranteeing continuity of QUIC session in wireless communication system

Abstract

The present disclosure relates to a 5G or 6G communication system for providing a higher data transmission rate beyond a 4G communication system such as LTE. A method of a first device in a communication system supporting a QUIC protocol according to the present disclosure comprises the steps of: receiving, from a second device, a handover request including a QUIC-SC context; and transmitting, to the second device, a response to the reception of the QUIC-SC context.

Description

Method and device for ensuring continuity of QUIC sessions in wireless communication systems

[0001] The present disclosure relates to the QUIC (quick UDP (user datagram protocol) internet connections)-SC (service continuity) protocol, and more particularly, to a method and device for ensuring continuity of a QUIC session when a QUIC endpoint is changed.

[0002] 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 the 5G (5th Generation) communication system, 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 6G (6th Generation) 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."

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

[0004] To achieve these high data rates and ultra-low latency, 6G communication systems are being considered for implementation in the terahertz (THz) band (e.g., from 95 gigahertz (GHz) to 3 terahertz (THz)). Compared to the millimeter wave (mmWave) band introduced in 5G, the terahertz band is expected to have more severe path loss and atmospheric absorption, making it more important to develop technologies that can guarantee signal reach, or coverage. 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 Surface (RIS) are being discussed to improve the coverage of terahertz band signals.

[0005] 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 at the same time for uplink and downlink; network technology that integrates satellites and HAPS (High-Altitude Platform Stations); 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 AI (Artificial Intelligence) 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.

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

[0007] Meanwhile, the QUIC (quick UDP (user datagram protocol) internet connections)-SC (service continuity) protocol is a new protocol that includes both the TCP (transmission control protocol) and TLS (transport layer security) protocols. Recently, the basic operating protocol of Internet services and networks is evolving to QUIC, and the development of QUIC technology is underway as a candidate protocol for providing metaverse services, one of the major applications of 5G-Adv / 6G. Specifically, discussions are being held on maximizing the throughput of IETF (internet engineering task force) MPQUIC (multipath QUIC), minimizing the delay of IETF MoQ (media over QUIC), and relaying between main terminals and metaverse devices in IETF QuicR (QUIC relay). In addition, the development of metaverse support standards (Rel. 19) and commercial technologies (e.g., platforms for providing metaverse services such as AR (augmented reality) / VR (virtual reality) glasses) is actively underway.

[0008] The disclosed embodiment is intended to provide a device and method capable of effectively providing a QUIC (quick UDP (user datagram protocol) internet connections) service.

[0009] More specifically, existing endpoints (e.g., metaverse devices) could be indirectly connected to an application server through a main terminal (e.g., user equipment (UE)), but when endpoints are directly connected to an application server, a device and method for ensuring continuity of QUIC services when endpoints are changed are provided.

[0010] According to various embodiments disclosed in the present document, a method of a first device in a communication system supporting a QUIC (quick user datagram protocol (UDP) internet connections) protocol according to one embodiment of the present disclosure comprises the steps of receiving a QUIC-SC (service continuity) context from a second device, and transmitting a response to the reception of the QUIC-SC context to the second device, wherein, based on the QUIC-SC context, an endpoint change of a QUIC connection to an application server is identified, and the endpoint change of the QUIC connection may include a migration of the QUIC connection from the second device to the first device.

[0011] According to various embodiments disclosed in the present document, a method of a network providing device in a communication system supporting a QUIC (quick UDP (user datagram protocol) internet connections) protocol, the method comprising the step of receiving a QUIC context from a second device, wherein a first device and the second device are devices that are connected to an application server via a wireless network and support an internet-based application service, and wherein each of the first device and the second device is connected to the application server via the QUIC protocol, and based on the QUIC-SC context, an endpoint change of a QUIC connection to the application server is identified, and the endpoint change of the QUIC connection may include a migration of the QUIC connection from the second device to the first device.

[0012] According to various embodiments disclosed in the present document, a communication system supporting a QUIC (quick user datagram protocol (UDP) internet connections) protocol comprises a first device, a transceiver, and at least one control unit coupled to the transceiver, wherein the at least one control unit receives a QUIC-SC (service continuity) context from a second device, transmits a response to the handover request to the second device, and, based on the QUIC-SC context, an endpoint change of a QUIC connection to an application server is identified, and the endpoint change of the QUIC connection may include a migration of the QUIC connection from the second device to the first device.

[0013] According to various embodiments disclosed in the present document, a network providing device in a communication system supporting a QUIC (quick UDP (user datagram protocol) internet connections) protocol, comprising a transceiver and at least one control unit coupled to the transceiver, wherein the at least one control unit receives a QUIC context from a second device, and each of the first device and the second device is connected to an application server via a wireless network and is a device supporting an internet-based application service, and each of the first device and the second device is connected to the application server via the QUIC protocol, and based on the QUIC-SC context, an endpoint change of a QUIC connection to the application server is identified, and the endpoint change of the QUIC connection may include a migration of the QUIC connection from the second device to the first device.

[0014] Methods and devices according to various embodiments of the present disclosure can ensure continuity of QUIC (quick user datagram protocol (UDP) internet connections) service when metaverse devices are changed when metaverse devices and application servers are directly connected via a wireless link.

[0015] Methods and devices according to various embodiments of the present disclosure can ensure continuity of QUIC service when a serving base station is changed from a source base station to a target base station when a handover of a terminal is performed in a communication system of 3GPP supporting the QUIC protocol.

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

[0017] FIG. 1 illustrates a communication network (100) including core network entities (or core network functions) in a wireless communication system according to various embodiments of the present disclosure.

[0018] FIG. 2 illustrates a wireless environment including a core network in a wireless communication system according to various embodiments of the present disclosure.

[0019] FIG. 3 illustrates the configuration of a core network object in a wireless communication system according to various embodiments of the present disclosure.

[0020] FIG. 4 illustrates a configuration of a base station in a wireless communication system according to various embodiments of the present disclosure.

[0021] FIG. 5 illustrates a configuration of a terminal in a wireless communication system according to various embodiments of the present disclosure.

[0022] FIG. 6 illustrates a protocol structure including a QUIC (quick user datagram protocol (UDP) internet connections) protocol related to various embodiments of the present disclosure.

[0023] FIG. 7 illustrates a protocol structure including a QUIC-based hypertext transfer protocol (HTTP) / 3 protocol related to various embodiments of the present disclosure.

[0024] FIG. 8 illustrates a network structure including a metaverse device related to various embodiments of the present disclosure.

[0025] FIG. 9 illustrates round-trip delay values ​​between a client device and a server in connection with various embodiments of the present disclosure.

[0026] FIG. 10 illustrates the internal structure of a device supporting QUIC-SC (service continuity) according to various embodiments of the present disclosure.

[0027] FIG. 11 illustrates a QUIC-SC context manifest according to various embodiments of the present disclosure.

[0028] FIG. 12 illustrates QUIC endpoint transition scenarios according to various embodiments of the present disclosure.

[0029] FIG. 13 illustrates the flow of signals in a QUIC endpoint switching operation in a first scenario according to various embodiments of the present disclosure.

[0030] FIG. 14 illustrates the sequence of QUIC endpoint transition operations in a first scenario according to various embodiments of the present disclosure.

[0031] FIG. 15 illustrates the flow of signals in a QUIC endpoint switching operation in a second scenario according to various embodiments of the present disclosure.

[0032] FIG. 16 illustrates the sequence of QUIC endpoint transition operations in a second scenario according to various embodiments of the present disclosure.

[0033] FIG. 17 illustrates the flow of signals in a QUIC endpoint switching operation in a third scenario according to various embodiments of the present disclosure.

[0034] FIG. 18 illustrates the sequence of QUIC endpoint transition operations in a third scenario according to various embodiments of the present disclosure.

[0035] FIG. 19 illustrates the flow of signals in a QUIC endpoint switching operation in a fourth scenario according to various embodiments of the present disclosure.

[0036] FIG. 20 illustrates the sequence of QUIC endpoint transition operations in a fourth scenario according to various embodiments of the present disclosure.

[0037] FIG. 21 illustrates a concept of a handover procedure according to various embodiments of the present disclosure.

[0038] FIG. 22 illustrates the flow of signals in a handover procedure according to various embodiments of the present disclosure.

[0039] FIG. 23 illustrates the operation sequence of a target base station in a handover procedure according to various embodiments of the present disclosure.

[0040] FIG. 24 illustrates an operation sequence of a target device according to various embodiments of the present disclosure.

[0041] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the attached drawings.

[0042] In describing the embodiments, descriptions of technical details that are well known in the technical field to which the present disclosure pertains and are not directly related to the present disclosure will be omitted. This is to ensure that the gist of the present disclosure is conveyed more clearly without obscuring it by omitting unnecessary explanations.

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

[0044] 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 together 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 only to ensure that the disclosure of the present 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 specification. In addition, when describing the present disclosure, if a specific description of a related function or configuration is determined to unnecessarily obscure the gist of the present disclosure, a detailed description thereof will be omitted. In addition, the terms described below are terms defined in consideration of the functions of the present disclosure, and may vary depending on the intention or custom of the user or operator. Therefore, their definitions should be made based on the contents throughout the specification.

[0045] Hereinafter, the base station is an entity that performs resource allocation of the terminal, and may be at least one of a gNode B, an eNode B, a Node B, a BS (Base Station), 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 cellular phone, a smartphone, a computer, or a multimedia system capable of performing a communication function. In the present disclosure, downlink (DL) refers to a wireless transmission path of a signal transmitted from a base station to a terminal, and uplink (UL) refers to a wireless transmission path of a signal transmitted from a terminal to a base station. In addition, although the LTE or LTE-A system may be described below as an example, the embodiments of the present disclosure may also be applied to other communication systems having a similar technical background or channel type. 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 without significantly departing from the scope of the present disclosure as judged by a person having skilled technical knowledge. For example, the present disclosure may be applied to a communication system supporting the QUIC (quick UDP (user datagram protocol) internet connections)-SC (service continuity) protocol. In this case, the communication system supporting the QUIC protocol may refer to a communication system that includes not only the terminal and base station described above, but also one or more metaverse devices. Therefore, the communication system referred to in the present disclosure below may refer to a communication system that includes a metaverse device as well as a conventional wireless communication system.Here, the metaverse can be a general term for various forms or contents that implement real-world interactions in a virtual space. In the embodiments of the present disclosure, a device that provides a metaverse service (e.g., augmented reality (AR) / virtual reality (VR) glasses) can be referred to as a metaverse device or a device for a metaverse service. However, although the embodiments of the present disclosure hereinafter exemplify a device that supports a metaverse service, the present disclosure is not limited thereto. A metaverse device, a device that supports a metaverse service, or a device for a metaverse service is merely an example of a device that supports an Internet-based application service. Therefore, the operating method of a device that supports a metaverse service in the embodiments of the present disclosure can be applied to a device that supports an Internet-based application service. In addition, in the embodiments of the present disclosure, a hotspot feeder is an example of a network providing device, and is not limited to a network structure that includes a hotspot feeder. Therefore, in the embodiments of the present disclosure, a hotspot feeder can refer to any device that provides a network, such as a base station or a wireless (WiFi) access point (AP).

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

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

[0048] The term 'unit or part' used in this disclosure means a software or hardware component such as a field-programmable gate array (FPGA) or an application specific integrated circuit (ASIC), and the 'unit' may be configured to perform specific roles. However, the 'unit' is not limited to software or hardware. The 'unit' may be configured to reside in an addressable storage medium and may be configured to execute 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 functionality 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'. Additionally, the components and '~parts' may be implemented to activate one or more CPUs within a device or secure multimedia card. In addition, in an embodiment, the '~parts' may include one or more processors and / or devices.

[0049] For convenience of explanation below, some terms and names defined in communication standards based on 3GPP (3rd Generation Partnership Project Long Term Evolution) (e.g., standards for 5G, NR, LTE, or similar systems) may be used. However, the present disclosure is not limited by these terms and names, and can be equally applied to systems conforming to other standards.

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

[0051] In embodiments of the present disclosure, the QUIC protocol may be a new protocol that includes both the transmission control protocol (TCP) and the transport layer security (TLS) protocol. The QUIC protocol may use UDP as the actual transport layer protocol as a transport protocol operating at the application layer.

[0052] When performing a migration between devices (e.g., a device supporting a metaverse / virtual reality service or a base station in a 3GPP communication system) in a communication system supporting the QUIC protocol, the QUIC connection of the existing device may need to be changed to a new device. Therefore, the following disclosure may describe methods for ensuring the continuity of a QUIC connection due to the migration of the QUIC connection. The methods described in the present disclosure may be applied when an endpoint (e.g., a device providing a metaverse service) is changed. In addition, the methods described in the present disclosure may also be applied when a serving base station is changed during a handover (HO) of a terminal in a 3GPP communication system. In the embodiments of the present disclosure below, the migration between devices in a communication system supporting the QUIC protocol may be referred to as an endpoint (QUIC connection or QUIC session) migration (movement or change). In the embodiments of the present disclosure below, a device providing a metaverse service may be referred to as an endpoint or an endpoint. In the embodiments of the present disclosure below, QUIC, quick, quick protocol, QUIC connection, or QUIC session may all be used with the same meaning as the QUIC protocol.

[0053] FIG. 1 illustrates a communication network (100) including core network entities (or core network functions) in a wireless communication system according to various embodiments of the present disclosure. A 5G mobile communication network may be configured to include a 5G user equipment (UE) (110), a 5G radio access network (RAN) (120), and a 5G core network (200).

[0054] The 5G core network may be configured to include network functions such as an access and mobility management function (AMF) (150) that provides a mobility management function of UE, a session management function (SMF) (160) that provides a session management function, a user plane function (UPF) (170) that performs a data transfer role, a policy control function (PCF) (180) that provides a policy control function, a unified data management (UDM) (153) that provides a data management function such as subscriber data and policy control data, or a unified data repository (UDR) that stores data of various network functions.

[0055] Referring to FIG. 1, a user equipment (UE) (110) may communicate with a base station (e.g., an eNB, a gNB) via a wireless channel, i.e., an access network. In some embodiments, the UE (110) may be a device used by a user and configured to provide a user interface (UI). As an example, the UE (110) may be a terminal mounted (equipment) on a vehicle for driving. In some other embodiments, the UE (110) may be a device that performs machine type communication (MTC) that operates without user intervention, or may be an autonomous vehicle. UE may be referred to as a 'terminal', 'vehicle terminal', 'user equipment (UE)', 'mobile station', 'subscriber station', 'remote terminal', 'wireless terminal', or 'user device' or other terms having equivalent technical meanings, other than electronic devices. As the terminal, in addition to the UE, a customer-premises equipment (CPE) or a dongle-type terminal may be used. The CPE, while connected to the NG-RAN node like the UE, may also provide a network to other communication devices (e.g., a laptop).

[0056] Referring to FIG. 1, the AMF (150) provides a function for connection and mobility management per terminal (110), and basically, one AMF (150) can be connected to one terminal (110). Specifically, the AMF (150) can perform at least one of signaling between core network nodes for mobility between 3GPP access networks, an interface (N2 interface) between wireless access networks (e.g., 5G RAN) (120), NAS signaling with the terminal (110), identification of the SMF (160), and provision of transmission of session management (SM) messages between the terminal (110) and the SMF (160). Some or all of the functions of the AMF (150) can be supported within a single instance of one AMF (150).

[0057] Referring to FIG. 1, the SMF (160) provides a session management function, and when the terminal (110) has multiple sessions, each session can be managed by a different SMF (160). Specifically, the SMF (160) can perform at least one of the following functions: session management (e.g., session establishment, modification, and release, including tunnel maintenance between the UPF (170) and the access network node), selection and control of UP (user plane) functions, traffic steering setup for routing traffic to an appropriate destination in the UPF (170), termination of the SM portion of NAS messages, downlink data notification (DDN), and initiation of AN-specific SM information (e.g., delivery to the access network via the N2 interface via the AMF (150)). Some or all of the functions of the SMF (160) can be supported within a single instance of one SMF (160).

[0058] In the 3GPP system, the conceptual links connecting network functions (NFs) within a 5G system can be referred to as reference points. Reference points can also be referred to as interfaces. The following illustrates reference points included in the 5G system architecture depicted in Figures 1 through 7.

[0059] - N1: Reference point between UE (110) and AMF (150)

[0060] - N2: Reference point between (R)AN(120) and AMF(150)

[0061] - N3: Reference point between (R)AN(120) and UPF(170)

[0062] - N4: Reference point between SMF (160) and UPF (170)

[0063] - N5: Reference point between PCF (180) and AF (130)

[0064] - N6: Reference point between UPF (170) and DN (140)

[0065] - N7: Reference point between SMF (160) and PCF (180)

[0066] - N8: Reference point between UDM (153) and AMF (150)

[0067] - N9: Reference point between two core UPFs (170)

[0068] - N10: Reference point between UDM (153) and SMF (160)

[0069] - N11: Reference point between AMF (150) and SMF (160)

[0070] - N12: Reference point between AMF (150) and authentication server function (AUSF) (151)

[0071] - N13: Reference point between UDM (153) and authentication server function (151)

[0072] - N14: Reference point between two AMFs (150)

[0073] - N15: For non-roaming scenarios, reference point between PCF (180) and AMF (150), for roaming scenarios, reference point between PCF (180) and AMF (150) within the visited network.

[0074] FIG. 2 illustrates a wireless environment including a core network in a wireless communication system according to various embodiments of the present disclosure.

[0075] Referring to FIG. 2, the wireless communication system includes a radio access network (RAN) (120) and a core network (CN) (200). In this case, the wireless communication system may be a communication system supporting the QUIC protocol of the present disclosure.

[0076] The wireless access network (120) is a network that is directly connected to a user device, for example, a terminal (110), and is an infrastructure that provides wireless access to the terminal (110). The wireless access network (120) includes a set of a plurality of base stations including a base station (125), and the plurality of base stations can communicate through interfaces formed between each other. At least some of the interfaces between the plurality of base stations can be wired or wireless. The base station (125) can have a structure that is divided into a central unit (CU) and a distributed unit (DU). In this case, one CU can control a plurality of DUs. The base station (125) can be referred to as an 'access point (AP)', 'next generation node B (gNB)', '5th generation node (5G node)', 'wireless point', 'transmission / reception point (TRP)', or other terms having an equivalent technical meaning thereto in addition to the base station. The terminal (110) connects to a wireless access network (120) and communicates with a base station (125) via a wireless channel. The terminal (110) may be referred to as a 'user equipment (UE)', a 'mobile station', a 'subscriber station', a 'remote terminal', a 'wireless terminal', a 'user device', or other terms having an equivalent technical meaning.

[0077] The core network (200) is a network that manages the entire system, controls the wireless access network (120), and processes data and control signals for terminals (110) transmitted and received through the wireless access network (120). The core network (200) performs various functions, such as controlling the user plane and the control plane, processing mobility, managing subscriber information, billing, and interworking with other types of systems (e.g., long term evolution (LTE) systems). In order to perform the various functions described above, the core network (200) may include a number of functionally separated entities having different NFs (network functions). For example, the core network (200) may include an access and mobility management function (AMF) (150), a session management function (SMF) (160), a user plane function (UPF) (170), a policy and charging function (PCF) (180), a network repository function (NRF) (159), a unified data management (UDM) (153), a network exposure function (NEF) (155), and a unified data repository (UDR) (157).

[0078] The terminal (110) is connected to the wireless access network (120) and accesses the AMF (150) that performs the mobility management function of the core network (200). The AMF (150) is a function or device that is in charge of both the connection to the wireless access network (120) and the mobility management of the terminal (110). The SMF (160) is an NF that manages sessions. The AMF (150) is connected to the SMF (160), and the AMF (150) routes session-related messages for the terminal (110) to the SMF (160). The SMF (160) is connected to the UPF (170) to allocate user plane resources to be provided to the terminal (110), and establishes a tunnel for transmitting data between the base station (125) and the UPF (170). PCF (180) controls information related to policies and charging for sessions used by terminal (110). NRF (159) stores information on NFs installed in a mobile communication operator network and performs a function of notifying the stored information. NRF (159) can be connected to all NFs. When each NF starts operating in the operator network, it registers with NRF (159) to notify NRF (159) that the corresponding NF is operating within the network. UDM (153) is an NF that performs a role similar to HSS (home subscriber server) of a 4G network, and stores subscription information of terminal (110) or context used by terminal (110) within the network.

[0079] The NEF (155) connects a third-party server and an NF within the 5G mobile communication system. It also provides data to, updates, or acquires data from the UDR (157). The UDR (157) stores subscription information for the terminal 120, policy information, data exposed externally, or information required for a third-party application. Furthermore, the UDR (157) provides stored data to other NFs.

[0080] FIG. 3 illustrates a configuration of a core network object in a wireless communication system according to various embodiments of the present disclosure. The configuration (200) illustrated in FIG. 3 may be understood as a configuration of a device having at least one function among those (150, 153, 155, 157, 160, 170, 180, 190) of FIG. 1. Terms such as “unit” and “unit” used hereinafter refer to a unit that processes at least one function or operation, which may be implemented by hardware, software, or a combination of hardware and software. The core network object of FIG. 3 may include a network function or network entity included in the core network. For example, the core network object of FIG. 3 may include any one of the AMF (150), SMF (160), UPF (170), PCF (180), NRF (159), UDM (153), NEF (155), and UDR (157) described above.

[0081] Referring to FIG. 3, the core network object is configured to include a communication unit (310), a storage unit (320), and a control unit (330).

[0082] The communication unit (310) provides an interface for communicating with other entities or functions within the network. That is, the communication unit (310) can transmit and receive signals with other entities within the core network or base stations of a wireless network. Accordingly, the communication unit (310) may be referred to as a modem, a transmitter, a receiver, or a transceiver. In this case, the communication unit (310) enables the core network entity to communicate with other devices or systems via a backhaul connection (e.g., wired backhaul or wireless backhaul) or via the network.

[0083] The storage unit (320) stores data such as basic programs, application programs, and configuration information for the operation of the core network object. The storage unit (320) may be composed of volatile memory, non-volatile memory, or a combination of volatile and non-volatile memory. In addition, the storage unit (320) provides the stored data upon request from the control unit (330).

[0084] The control unit (330) controls the overall operations of the core network object. For example, the control unit (330) transmits and receives signals through the communication unit (310). In addition, the control unit (330) records and reads data from the storage unit (320). For this purpose, the control unit (330) may include at least one processor. According to various embodiments of the present disclosure, the control unit (330) may control the core network object to perform operations according to various embodiments described below.

[0085] FIG. 4 illustrates the configuration of a base station in a wireless communication system according to various embodiments of the present disclosure. The configuration illustrated in FIG. 4 can be understood as the configuration of a base station (125). Terms such as "~unit" and "~unit" used hereinafter refer to a unit that processes at least one function or operation, and may be implemented using hardware, software, or a combination of hardware and software.

[0086] Referring to FIG. 4, the base station (125) includes a wireless communication unit (410), a backhaul communication unit (420), a storage unit (430), and a control unit (440).

[0087] The wireless communication unit (410) performs functions for transmitting and receiving signals via a wireless channel. For example, the wireless communication unit (410) performs a conversion function between baseband signals and bit streams according to the physical layer specifications of the system. For example, when transmitting data, the wireless communication unit (410) encodes and modulates the transmitted bit stream to generate complex symbols. Furthermore, when receiving data, the wireless communication unit (410) restores the received bit stream by demodulating and decoding the baseband signal.

[0088] In addition, the wireless communication unit (410) upconverts a baseband signal into an RF (radio frequency) band signal and transmits it through an antenna, and downconverts an RF band signal received through the antenna into a baseband signal. To this end, the wireless communication unit (410) 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 addition, the wireless communication unit (410) may include a plurality of transmission and reception paths. Furthermore, the wireless communication unit (410) may include at least one antenna array composed of a plurality of antenna elements.

[0089] In terms of hardware, the wireless communication unit (410) may be composed of a digital unit and an analog unit, and the analog unit may be composed of a plurality of sub-units depending on operating power, operating frequency, etc. The digital unit may be implemented with at least one processor (e.g., a digital signal processor (DSP)).

[0090] The wireless communication unit (410) transmits and receives signals as described above. Accordingly, all or part of the wireless communication unit (410) may be referred to as a "transmitter," a "receiver," or a "transceiver." Furthermore, in the following description, transmission and reception performed via a wireless channel are used to mean that the wireless communication unit (410) performs the processing described above.

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

[0092] The storage unit (430) stores data such as basic programs, application programs, and setting information for the operation of the base station. The storage unit (430) may be composed of volatile memory, nonvolatile memory, or a combination of volatile and nonvolatile memory. In addition, the storage unit (430) provides stored data upon request from the control unit (440).

[0093] The control unit (440) controls the overall operations of the base station. For example, the control unit (440) transmits and receives signals through the wireless communication unit (410) or the backhaul communication unit (420). In addition, the control unit (440) records and reads data in the storage unit (430). In addition, the control unit (440) can perform the functions of the protocol stack required by the communication standard. According to another implementation example, the protocol stack can be included in the wireless communication unit (410). For this purpose, the control unit (440) can include at least one processor. According to various embodiments, the control unit (440) can control the base station to perform operations according to various embodiments described below.

[0094] Additionally, the base station (125) can be connected via UPF (170) and a QUIC-based flow. Accordingly, the base station (125) can configure a PDU (protocol data unit) session with the terminal (110) using the QUIC protocol.

[0095] FIG. 5 illustrates the configuration of a terminal in a wireless communication system according to various embodiments of the present disclosure. The configuration illustrated in FIG. 5 can be understood as the configuration of a terminal (110). Terms such as "~unit" and "~unit" used hereinafter refer to a unit that processes at least one function or operation, which can be implemented using hardware, software, or a combination of hardware and software.

[0096] Referring to FIG. 5, the terminal includes a communication unit (510), a storage unit (520), and a control unit (530).

[0097] The communication unit (510) performs functions for transmitting and receiving signals via a wireless channel. For example, the communication unit (510) 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 communication unit (510) generates complex symbols by encoding and modulating a transmission bit stream. In addition, when receiving data, the communication unit (510) restores a reception bit stream by demodulating and decoding the baseband signal. In addition, the communication unit (510) upconverts a baseband signal to an RF band signal and transmits it through an antenna, and downconverts an RF band signal received through the antenna to a baseband signal. For example, the communication unit (510) may include a transmission filter, a reception filter, an amplifier, a mixer, an oscillator, a DAC, an ADC, etc.

[0098] In addition, the communication unit (510) may include a plurality of transmission and reception paths. Furthermore, the communication unit (510) may include at least one antenna array composed of a plurality of antenna elements. In terms of hardware, the communication unit (510) may be composed of digital circuits and analog circuits (e.g., a radio frequency integrated circuit (RFIC)). Here, the digital circuits and analog circuits may be implemented in a single package. In addition, the communication unit (510) may include a plurality of RF chains. Furthermore, the communication unit (510) may perform beamforming.

[0099] The communication unit (510) transmits and receives signals as described above. Accordingly, all or part of the communication unit (510) may be referred to as a "transmitter," a "receiver," or a "transmitting and receiving unit." Furthermore, in the following description, transmission and reception performed via a wireless channel are used to mean processing performed by the communication unit (510) as described above.

[0100] The storage unit (520) stores data such as basic programs, application programs, and setting information for the operation of the terminal. The storage unit (520) may be composed of volatile memory, non-volatile memory, or a combination of volatile and non-volatile memory. In addition, the storage unit (520) provides stored data upon request from the control unit (530).

[0101] The control unit (530) controls the overall operations of the terminal. For example, the control unit (530) transmits and receives signals through the communication unit (510). In addition, the control unit (530) records and reads data in the storage unit (520). In addition, the control unit (530) can perform the functions of the protocol stack required by the communication standard. To this end, the control unit (530) may include at least one processor or microprocessor, or may be a part of a processor. In addition, a part of the communication unit (510) and the control unit (530) may be referred to as a CP (communication processor). According to various embodiments, the control unit (530) may control the terminal to perform operations according to various embodiments described below.

[0102] Additionally, the terminal (110) may be connected to at least one metaverse device via a wireless link (e.g., WiFi, RF (radio frequency)). Accordingly, at least one metaverse device and an application server (or app server) may transmit and / or receive necessary information via the terminal (110).

[0103] FIG. 6 illustrates a protocol structure including a QUIC protocol related to various embodiments of the present disclosure.

[0104] Referring to Figure 6, the structure of the Internet transport protocol related to the Hypertext Transfer Protocol (HTTP) protocol is described. The QUIC protocol can include both TCP and TLS protocols. The QUIC protocol is a transport protocol that operates at the application layer and can use UDP as the actual transport layer protocol. Therefore, the QUIC protocol can implement all functions that UDP does not provide (e.g., multi-streaming, TLS 1.3, congestion control, and loss recovery) at the application layer. In addition, functions other than the functions described above can be implemented in QUIC. The QUIC protocol adopts UDP as a transport protocol, which can provide lower latency and higher throughput than TCP, and can bypass network middleboxes that can interfere with TCP. The QUIC protocol includes a built-in encryption protocol based on TLS 1.3, which can provide secure communication between endpoints. Therefore, the QUIC protocol can reduce or prevent third parties from intercepting and manipulating Internet traffic.

[0105] FIG. 7 illustrates a protocol structure including a QUIC-based HTTP / 3 protocol in connection with various embodiments of the present disclosure.

[0106] Referring to Figure 7, QUIC technology is being developed as a candidate protocol for providing metaverse services, a key application of 5G-Adv / 6G. Before the launch of QUIC technology, TCP was the primary protocol for transmitting data over HTTP. However, with the continuous development of the mobile Internet, the demand for real-time interaction and more diverse network scenarios is increasing. Furthermore, portable devices such as smartphones are becoming increasingly mainstream, with over 60% of Internet traffic currently transmitted wirelessly. However, TCP, a transport layer communication protocol in use for over 40 years, can have inherent performance bottlenecks in situations such as large-scale long-distance communications, poor mobile networks, and frequent network transitions. With the advent of the QUIC IETF-v1 protocol standard, more websites are using QUIC traffic, and statistics show that approximately 25.5% of websites currently use HTTP / 3.

[0107] FIG. 8 illustrates a network structure including a metaverse device related to various embodiments of the present disclosure.

[0108] Referring to Figure 8, a network structure is illustrated in which an application server and a metaverse device are indirectly connected via a terminal. At this time, the screen used by the user is mirrored between the user's device (e.g., the terminal) and the metaverse device (e.g., the AR / VR device), thereby providing application-level continuity.

[0109] However, if the metaverse device is indirectly connected to the application server through the terminal, it may be difficult for the user to use it for a long time due to heat issues caused by excessive energy consumption, and the usage time of the metaverse device may be shortened. In addition, the processing capability of the terminal AP (application processor) (e.g., application processing, screen mirroring processing, or packet forwarding) may be reduced. In addition, since the metaverse device forwards data to the application server through the terminal, the time required for data transmission (e.g., transmission delay from the terminal to the metaverse device of 4.5 msec) may increase compared to the delay requirement for the metaverse service (e.g., 1 msec). Therefore, a direct connection between the metaverse device and the application server may be required. For example, a metaverse device can connect directly to an application server via a wireless link (e.g., Wi-Fi direct, neighbor awareness networking (NAN), WiFi 802.11ay, WiFi 802.11bb, RF) without going through a terminal. However, even when the metaverse device is changed, the continuity of the QUIC connection with the application server must be guaranteed, but the following delay issues may occur.

[0110] FIG. 9 illustrates round trip time (RTT) values ​​between a client device and a server in connection with various embodiments of the present disclosure.

[0111] Referring to Figure 9, when one of the endpoints of a pair of devices changes, a new connection must be established, and a round-trip delay issue may occur due to the new connection. For example, a continuous connection with 0 RTT can be maintained for a context (e.g., IP (internet protocol) address, routing rule, access network) transition that occurs between the same pair (e.g., between endpoints). On the other hand, when one of the endpoints changes between different pairs of devices, the context of the QUIC connection before the change (e.g., security token, Connection ID, Stream ID Set) cannot be maintained, so a delay may occur in the process of establishing a new connection. This may be because the changed endpoint does not know the existing QUIC context (e.g., the context of the QUIC session with the endpoint before the change).

[0112] More specifically, referring to Fig. 9(a), the round-trip delay (RTT) values ​​that may occur when creating a new connection between a client device and a server can be explained. Since TCP and TLS each perform an end-to-end handshake (or handshake), at least two end-to-end handshakes can be performed. For example, in a-1), 3 RTTs may occur between the client device and the server during the connection establishment process of TCP and TLS version 1.2. In a-2), 2 RTTs may also occur between the client device and the server during the connection establishment process of TCP and TLS version 1.3. On the other hand, since QUIC is designed as a single protocol that combines TCP and TLS, it can create a new session by performing only one end-to-end handshake at the beginning. In addition, QUIC can continue the session without a separate handshake even if the intermediate transmission path changes or the IP of the endpoint changes. For example, in case of QUIC in a-3), only 1 RTT can occur between the client device and the server because only one end-to-end handshake is performed initially.

[0113] On the other hand, referring to FIG. 9(b), the round trip delay (RTT) values ​​that may occur when performing a reconnection between a client device and a server (e.g., when one endpoint does not change) can be explained. In b-1), 2 RTTs may occur between the client device and the server during the connection establishment process of TCP and TLS versions 1.2. In b-2), 1 RTT may also occur between the client device and the server during the connection establishment process of TCP and TLS versions 1.3. On the other hand, in b-3), in the case of QUIC, a round trip delay between the client device and the server may not occur because TCP and TLS handshakes are not required for reconnection.

[0114] In the embodiments of the present disclosure below, a method for maintaining continuity of a QUIC connection even when one endpoint is changed is presented, taking into account the example of b-3) described above. At this time, a method for maintaining continuity of a QUIC connection between different endpoints may be referred to as QUIC-SC (service continuity). In QUIC, when an endpoint is continuously maintained, only a context change between endpoints could be handled, so a new connection may need to be established when an endpoint is changed. On the other hand, QUIC-SC of the present disclosure can provide a flexible experience transition between a user terminal and a service device (e.g., a metaverse device) for high-spec services using QUIC, and communication continuity can be guaranteed when a base station or traffic anchor is switched in a QUIC-based network or cloud.

[0115] In the embodiments of the present disclosure below, a device that previously provided a metaverse service using a QUIC session (or a device that provided a metaverse service before the QUIC endpoint was changed) may be referred to as a source device or a first device. A device that will subsequently receive the QUIC session (or a device that will receive the metaverse service after the QUIC endpoint is changed) may be referred to as a target device or a second device. Accordingly, both the first device and the second device may be any devices capable of providing a metaverse service.

[0116] FIG. 10 illustrates the internal structure of a device supporting QUIC-SC according to various embodiments of the present disclosure.

[0117] Referring to Figure 10, a newly defined protocol structure (e.g., a sub-module) may be described to maintain continuity of QUIC connections between different endpoints. Hereinafter, the newly defined QUIC-SC protocol structure may be referred to as a module, an application, or a class.

[0118] In one embodiment, each device may include an upper-level module, called the multi-device connectivity framework (MCF), that processes user commands related to device switching. Additionally, sub-modules within the QUIC-SC module may be defined. For example, the QUIC-SC module may include at least one of a context manager and a connection manager. The context manager can be connected via an application programming interface (API) between QUIC and an external framework (e.g., MCF). The context manager can be a submodule that provides a QUIC context to the connection manager, or passes a QUIC context provided from QUIC to an external source (e.g., an endpoint to be changed). The connection manager can also be connected to the context manager via an API. The connection manager can be a submodule that establishes a QUIC connection using an input QUIC context, or extracts an existing QUIC context (e.g., a QUIC context used by an endpoint before the change). In this case, the API can be an external interface for triggering a QUIC-SC endpoint transition.

[0119] More specifically, at step 1005, when an intent or command related to a user device transition is input to the MCF of the first device, the MCF may call the ep_migration_init() function (or function) provided by the QUIC-SC context manager. At this time, ep_migration_init() may be an interface that notifies QUIC-SC of an event that requires an endpoint transition.

[0120] At step 1010, the QUIC-SC context manager, which has received an event requiring a migration point via ep_migration_init(), can temporarily stop communication between the existing QUIC-based application server and QUIC-SC by calling the connection manager's conn_stop() function (or functions).

[0121] At step 1015, if communication is interrupted, the connection manager can call the context manager's conn_stop_done(context) function (or functions) to pass the context of the QUIC communication session so far.

[0122] At step 1020, the context manager can process the context of the QUIC session received through step 1030 into a manifest structure and then pass the manifest to the MCF by calling the ep_migration_context(manifest) function (or function).

[0123] At step 1025, the MCF may include the received manifest in a handoff (or handover) request message (e.g., a handoff advertisement request) and forward it to the MCF of the second device. The handoff request message may be transmitted directly between devices (e.g., via Bluetooth low energy (BLE), NAN, or Wi-Fi Direct), or may be transmitted via an entity such as a 3GPP base station or a WiFi router. The handoff request message is merely an example, and may be included in another message or the manifest alone may be transmitted.

[0124] At step 1030, the MCF of the second device can pass the manifest received from the MCF of the first device to the context manager within the QUIC-SC module by calling ep_migration_cmd(manifest).

[0125] At step 1035, the context manager can detach the context of the existing QUIC session using the manifest received from the MCF of the second device, and request the creation of a QUIC session with the detached context by calling the conn_migration(context) function (or function) provided by the connection manager.

[0126] At step 1040, the connection manager can perform a QUIC connection transition procedure using a separate context, as if the IP address of the QUIC endpoint had changed. The QUIC connection transition procedure involves exchanging probing packets between the connection manager and the QUIC-based application server.

[0127] At step 1045, after the QUIC connection migration procedure is complete, the connection manager can call the context manager's conn_migration_completed() function (or function) to communicate whether the QUIC connection migration was successful.

[0128] At step 1050, the context manager may call the ep_migration_done() function (or functions) to notify the MCF of the second device of the final success of the QUIC connection transition.

[0129] Of course, this is not limited to the above examples. The QUIC endpoint transition procedure in the above-described embodiment may involve a combination or modification of at least one operation, in part or in whole. Alternatively, at least one operation may be deleted or a new procedure may be added, organically combining the above-described operations.

[0130] At this time, the QUIC context structure transmitted between different endpoints may be referred to as a QUIC-SC context manifest. In an embodiment of the present disclosure, the QUIC-SC context and the QUIC-SC context manifest may be defined as follows.

[0131] FIG. 11 illustrates a QUIC-SC context manifest according to various embodiments of the present disclosure.

[0132] Referring to FIG. 11, a QUIC-SC context and a QUIC-SC context manifest can be defined. For example, the QUIC-SC context can include at least one of a connection ID, a QUIC version, a set of stream IDs, or a set of packet numbers. The QUIC-SC context can refer to a set of metadata required to continue a QUIC connection as is. In addition, the QUIC-SC context manifest (or manifest) can mean a normalized method, structure, or field for expressing metadata.

[0133] Referring back to FIG. 11, the QUIC-SC context manifest may be an embodiment of a manifest that the MCF of the first device transmits to the MCF of the second device in step 1025 of FIG. 10 described above. Of course, the present invention is not limited to the example of FIG. 11. The first device transmits a QUIC-SC context manifest containing a QUIC-SC context to the second device, thereby performing a transition procedure of the QUIC endpoint.

[0134] FIG. 12 illustrates QUIC endpoint transition scenarios according to various embodiments of the present disclosure.

[0135] Referring to FIG. 12, different scenarios of QUIC endpoint transition procedures depending on the network structure can be described when a QUIC endpoint changes from a first device to a second device.

[0136] In one embodiment, the first scenario (S1) in (a) of FIG. 12 may be a QUIC endpoint transition procedure that can be performed in the network structure of FIG. 10 described above. Specifically, in the first scenario, the first device and the second device may be directly connected (e.g., peer-to-peer (P2P) communication) via a wireless link. Accordingly, the first device may directly transfer a QUIC-SC context (e.g., step 1025) to the second device via the wireless link.

[0137] In one embodiment, the second scenario (S2) in (b) of FIG. 12 may be a QUIC endpoint transition procedure that can be performed in a network structure in which a hotspot feeder (e.g., a hotspot device connected to the same or different user accounts as the first and second devices) exists between devices and an application server. Specifically, in the second scenario, as in the first scenario, the first device can directly transfer a QUIC-SC context (e.g., step 1025) to the second device via a wireless link. However, the second device can transmit and / or receive discovery packets and data packets to and from the application server via the hotspot feeder. In this case, the hotspot device connected to the same user account as the first and second devices may be a trusted device. On the other hand, the hotspot device connected to a different user account from the first and second devices may be an untrusted device. The description of the hotspot feeder described above may also be applied to the following embodiments.

[0138] In one embodiment, the third scenario (S3) in (c) of FIG. 12 may be a QUIC endpoint switching procedure that can be performed in a network structure where a hotspot feeder (e.g., a hotspot device connected to the same user account as the first device and the second device) exists between the devices and the application server. Specifically, the first device and the second device may not be directly connected via a wireless link. Therefore, in the third scenario, unlike the first and second scenarios, it may be difficult for the first device to directly transfer the QUIC-SC context (e.g., step 1025) to the second device via a wireless link. However, the first device may obtain the IP address of the second device through identification information (e.g., a unique address (e.g., a medium access control (MAC) address), a port, or an identifier) ​​of the second device connected to the same user account. In addition, the second device may transmit and / or receive discovery packets and data packets to and from the application server via the hotspot feeder, similar to the second scenario.

[0139] In one embodiment, the fourth scenario (S4) in (d) of FIG. 12 may be a QUIC endpoint switching procedure that can be performed in a network structure where a hotspot feeder (e.g., a hotspot device associated with different user accounts from the first device and the second device) exists between devices and an application server. Specifically, the first device and the second device may not be directly connected via a wireless link. Therefore, in the fourth scenario, unlike the first and second scenarios, it may be difficult for the first device to directly transfer a QUIC-SC context (e.g., step 1025) to the second device via a wireless link. Furthermore, the first device may have difficulty obtaining the IP address of the second device via a hotspot feeder associated with a different user account. Therefore, the first device may transfer the QUIC-SC context to the second device via the application server. Thereafter, the second device may transmit and / or receive discovery packets and data packets to and from the application server via the hotspot feeder, similar to the second scenario.

[0140] FIG. 13 illustrates the flow of signals in a QUIC endpoint switching operation in a first scenario according to various embodiments of the present disclosure.

[0141] Referring to FIG. 13, the operations of each device and application server in the QUIC endpoint transition operation based on the first scenario described above can be described. At step 1305, the first device can transmit a non-probing packet to the application server. In this case, the non-probing packet may refer to a data packet containing data for providing a metaverse service to a user, unlike a probing packet transmitted to notify the application server of a change in endpoint or path.

[0142] At step 1310, the application server is in transition and can therefore send the non-search packet requested by the user to the first device.

[0143] At step 1315, the first device may transmit a QUIC context to the second device. At this time, the transmitted QUIC context may refer to the QUIC-SC context included in the handover request of step 1025 described above. Accordingly, the QUIC context may include information about the QUIC connection between the first device and the application server (e.g., at least one of a connection ID, a QUIC version, a set of stream IDs, or a set of packet numbers).

[0144] In step 1320, when the second device receives a QUIC context from the first device, the second device may transmit a response message (e.g., ACK (acknowledgement) or NACK (negative acknowledgment)) regarding whether the QUIC context reception was successful. At this time, if the second device does not successfully receive the QUIC context, it may transmit a NACK to the first device. If the first device receives a NACK from the second device, it may transmit the QUIC context to the second device. However, the retransmitted QUIC context may not be identical to the QUIC context transmitted in step 1315 described above. For example, each QUIC context may have a different redundancy value. At this time, the redundancy value may be a value indicating whether to retransmit the transmitted data (or the number of retransmissions).

[0145] At step 1325, if the second device successfully receives a QUIC context from the first device (e.g., if it sends an ACK to the first device), the second device may transmit a probing packet (e.g., a PATH_CHALLENGE packet) to the application server. The probing packet may include information indicating to the application server a change in endpoint (e.g., an endpoint change from the first device to the second device).

[0146] At step 1330, the application server may transmit a response (e.g., a PATH_RESPONSE packet) to the second device in response to receiving the probe packet. The response to receiving the probe packet may be an ACK or a NACK. If the response to receiving the probe packet is an ACK, the second device that received the ACK may not retransmit the probe packet to the application server. The application server may identify that the endpoint has changed based on the probe packet. However, the application server may also identify that the transmission path to the same endpoint (e.g., the first device) has changed.

[0147] At step 1335, the application server may send a discovery packet (e.g., a PATH_CHALLENGE packet) to the second device.

[0148] In step 1340, the second device may transmit a response to the application server regarding the success or failure of receiving the probe packet, in the same manner as in step 1330. However, the responses in steps 1330 and 1340 may each include different information. By transmitting and / or receiving the probe packet, the application server may perform data transmission and / or reception procedures with the second device.

[0149] At step 1345, the second device may transmit a non-search packet (e.g., a data packet) to the application server.

[0150] At step 1350, the application server may transmit non-navigational packets (e.g., data packets) to the second device. The non-navigational packets transmitted at steps 1345 and 1350 may contain data for providing metaverse services to the user.

[0151] Of course, this is not limited to the above examples. The QUIC endpoint transition procedure according to the first scenario in the above-described embodiment may involve a combination or modification of some or all of the operations. Alternatively, at least one operation may be deleted or a new procedure may be added to organically combine the above-described operations.

[0152] FIG. 14 illustrates the sequence of QUIC endpoint transition operations in a first scenario according to various embodiments of the present disclosure.

[0153] Referring to FIG. 14, the operation sequence of the second device in the QUIC endpoint switching procedure according to the first scenario of FIG. 13 described above may be described. However, any description overlapping with that of FIG. 13 described above may be omitted.

[0154] At step 1410, the second device may receive a QUIC context from the first device. At this time, the QUIC context may refer to a QUIC-SC context included in a handover request (e.g., step 1025), similar to FIG. 13 described above.

[0155] At step 1420, when the second device receives the QUIC context from the first device, the second device may transmit a response message (e.g., ACK or NACK) regarding whether the QUIC context reception was successful. At this time, if the second device does not successfully receive the QUIC context, the second device may transmit a NACK to the first device. When the first device receives a NACK from the second device, the first device may transmit the QUIC context to the second device. However, the retransmitted QUIC context may not be identical to the initially received QUIC context described above. For example, each QUIC context may have a different redundancy value.

[0156] At step 1430, if the second device successfully receives a QUIC context from the first device (e.g., if an ACK is transmitted to the first device), the second device may transmit and / or receive a probe packet (e.g., a PATH_CHALLENGE packet) to and from the application server. At this time, the probe packet may include information indicating to the application server that the endpoint has changed (e.g., from the first device to the second device). Accordingly, the application server may identify that the endpoint has changed based on the probe packet. However, the application server may also identify that the transmission path for the same endpoint (e.g., the first device) has changed.

[0157] At step 1440, the second device can transmit and / or receive non-browser packets (e.g., data packets) containing data for providing metaverse services to the application server and the user.

[0158] Of course, this is not limited to the above examples. Some or all of the QUIC endpoint transition operations of the second device according to the first scenario in the above-described embodiment may be combined or modified. Alternatively, at least one operation may be deleted or a new procedure may be added to organically combine with the above-described operations.

[0159] FIG. 15 illustrates the flow of signals in a QUIC endpoint switching operation in a second scenario according to various embodiments of the present disclosure.

[0160] Referring to FIG. 15, the operations of each device, the hotspot feeder, and the application server in the QUIC endpoint transition operation based on the second scenario described above can be described. At step 1505, the first device can transmit a non-discovery packet to the application server via the hotspot feeder. In this case, the non-discovery packet can refer to a data packet containing data for providing a metaverse service to a user, unlike a discovery packet transmitted to notify the application server of a change in endpoint or path.

[0161] At step 1510, the application server can transmit the non-discovery packet requested by the user to the first device via the hotspot feeder. The transmission and / or reception of the non-discovery packet between the first device and the application server in steps 1505 and 1510 described above can be performed without changing the transmission / reception ports, as this occurs before the endpoints are switched.

[0162] At step 1515, the first device may transmit a QUIC context to the second device. At this time, the transmitted QUIC context may refer to the QUIC-SC context included in the handover request of step 1025 described above. Accordingly, the QUIC context may include information about the QUIC connection between the first device and the application server (e.g., at least one of a connection ID, a QUIC version, a set of stream IDs, or a set of packet numbers).

[0163] In step 1520, when the second device receives a QUIC context from the first device, the second device may transmit a response message (e.g., ACK or NACK) regarding whether the QUIC context reception was successful. At this time, if the second device does not successfully receive the QUIC context, the second device may transmit a NACK to the first device. If the first device receives a NACK from the second device, the first device may transmit the QUIC context to the second device. However, the retransmitted QUIC context may not be identical to the QUIC context transmitted in step 1515 described above. For example, each QUIC context may have a different redundancy value. At this time, the redundancy value may be a value indicating whether to retransmit the transmitted data (or the number of retransmissions).

[0164] At step 1525, if the second device successfully receives a QUIC context from the first device (e.g., if it sends an ACK to the first device), the second device may transmit a probe packet (e.g., a PATH_CHALLENGE packet) to the application server via the hotspot feeder. The probe packet may include information indicating to the application server a change in endpoint (e.g., an endpoint change from the first device to the second device).

[0165] At step 1530, the application server may transmit a response (e.g., a PATH_RESPONSE packet) to the second device via the hotspot feeder for receiving the probe packet. The response to receiving the probe packet may be an ACK or a NACK. If the response to receiving the probe packet is an ACK, the second device that received the ACK may not retransmit the probe packet to the application server. The application server may identify that the endpoint has changed based on the probe packet. However, the application server may also identify that the transmission path to the same endpoint (e.g., the first device) has changed.

[0166] At step 1535, the application server may send a probe packet (e.g., a PATH_CHALLENGE packet) to the second device via the hotspot feeder.

[0167] In step 1540, the second device may transmit a response regarding whether the discovery packet was successfully received to the application server via the hotspot feeder, in the same manner as in step 1530. However, the responses in steps 1530 and 1540 may each include different information. By transmitting and / or receiving the discovery packet, the application server may perform a data transmission and / or reception procedure with the second device. In one embodiment, the discovery packet may include information for updating a network address translation (NAT) (or NAT table). In embodiments of the present disclosure, the NAT table may refer to a table or database that includes a 1:1 mapping relationship between identification information (e.g., a unique address (e.g., a MAC address), a port, or an identifier) ​​of each of the first device and / or the second device and an IP. Hereinafter, in embodiments of the present disclosure, the NAT table may be used with the same meaning. Information for updating the NAT table may include change information regarding the connection relationship between the IP address of each device (e.g., the first device and the second device) and the port of the hotspot feeder. Accordingly, the transmission / reception ports may be changed through transmission and / or reception of discovery packets between the second device and the application server via the hotspot feeder. For example, the transmission / reception ports (e.g., I:i, H:h1) of the first device and the hotspot feeder in steps 1505 and 1510 may be changed to the transmission / reception ports (e.g., T:t, H:h2) of the second device and the hotspot feeder in steps 1525 to 1540.

[0168] At step 1545, the second device may transmit a non-search packet (e.g., a data packet) to the application server.

[0169] At step 1550, the application server may transmit non-discovery packets (e.g., data packets) to the second device. The non-discovery packets transmitted at steps 1545 and 1550 may contain data for providing metaverse services to users, and may be transmitted and / or received without passing through a hotspot feeder.

[0170] Of course, this is not limited to the above examples. The QUIC endpoint transition procedure according to the second scenario in the above-described embodiment may involve a combination or modification of some or all of the operations. Alternatively, at least one operation may be deleted or a new procedure may be added to organically combine the above-described operations.

[0171] FIG. 16 illustrates the sequence of QUIC endpoint transition operations in a second scenario according to various embodiments of the present disclosure.

[0172] Referring to FIG. 16, the operation sequence of the second device in the QUIC endpoint switching procedure according to the second scenario of FIG. 15 described above may be described. However, any description overlapping with that of FIG. 15 described above may be omitted.

[0173] At step 1610, the second device may receive a QUIC context from the first device. At this time, the QUIC context may refer to a QUIC-SC context included in a handover request (e.g., step 1025), similar to FIG. 15 described above.

[0174] At step 1620, when the second device receives a QUIC context from the first device, the second device may transmit a response message (e.g., ACK or NACK) to the first device regarding whether the QUIC context reception was successful. At this time, when the second device does not successfully receive the QUIC context, the second device may transmit a NACK to the first device. When the first device receives a NACK from the second device, the first device may transmit the QUIC context to the second device. However, the retransmitted QUIC context may not be identical to the initially received QUIC context described above. For example, each QUIC context may have a different redundancy value.

[0175] At step 1630, if the second device successfully receives a QUIC context from the first device (e.g., transmits an ACK to the first device), the second device may transmit and / or receive a probe packet (e.g., a PATH_CHALLENGE packet) through the application server and the hotspot feeder. The probe packet may include information indicating to the application server that an endpoint has changed (e.g., from the first device to the second device). Accordingly, the application server may identify that the endpoint has changed based on the probe packet. However, the application server may also identify that a transmission path for the same endpoint (e.g., the first device) has changed. In addition, the probe packet may include information for updating a NAT table. The information for updating the NAT table may include information about a change in the connection relationship between the IP address of each device (e.g., the first device and the second device) and the port of the hotspot feeder. Therefore, the transmitting / receiving ports can be changed through transmission and / or reception of discovery packets between the second device and the application server via the hotspot feeder.

[0176] At step 1640, the second device may transmit and / or receive non-navigational packets (e.g., data packets) containing data for providing metaverse services to the application server and the user. The non-navigational packets may be transmitted and / or received without passing through a hotspot feeder.

[0177] Of course, this is not limited to the above examples. Some or all of the QUIC endpoint transition operations of the second device according to the second scenario in the above-described embodiment may be combined or modified. Alternatively, at least one operation may be deleted or a new procedure may be added to organically combine with the above-described operations.

[0178] FIG. 17 illustrates the flow of signals in a QUIC endpoint switching operation in a third scenario according to various embodiments of the present disclosure.

[0179] Referring to FIG. 17, the operations of each device, the hotspot feeder, and the application server in the QUIC endpoint switching operation based on the third scenario described above can be described. At step 1705, the first device can transmit a non-discovery packet to the application server via the hotspot feeder. In this case, the non-discovery packet can refer to a data packet containing data for providing a metaverse service to a user, unlike a discovery packet transmitted to notify the application server of a change in endpoint or path.

[0180] At step 1710, the application server can transmit the non-discovery packet requested by the user to the first device via the hotspot feeder. The transmission and / or reception of the non-discovery packet between the first device and the application server in steps 1705 and 1710 described above can be performed without changing the transmission / reception ports, as it occurs before the endpoints are switched.

[0181] At step 1715, the first device may transmit a message (e.g., an address resolution protocol (ARP) request) to the hotspot feeder to request identification information (e.g., a unique address (e.g., a MAC address), a port, or an identifier) ​​of the second device. For example, the APR request may include the MAC address of the second device. In the third scenario, since there is no direct link between the first device and the second device, they may obtain each other's IP addresses through the hotspot feeder. In this case, it may be assumed that the first device and the second device are devices included in the same user account and that the MAC addresses of the two devices are known. Of course, the present invention is not limited to the above example. Accordingly, the request to identify the second device may be included not only in the APR request, but also in a pilot message of a 3GPP communication system.

[0182] At step 1720, the hotspot feeder may send a response message (e.g., an ARP response) to the second device. For example, the ARP response may include the IP address of the second device connected to the hotspot feeder. Accordingly, the first device may obtain the IP address of the second device.

[0183] At step 1725, the first device may transmit a QUIC context to the second device based on the IP address of the second device acquired at step 1720. At this time, the transmitted QUIC context may refer to the QUIC-SC context included in the handover request of step 1025 described above. Accordingly, the QUIC context may include information about the QUIC connection between the first device and the application server (e.g., at least one of a connection ID, a QUIC version, a set of stream IDs, or a set of packet numbers).

[0184] At step 1730, when the second device receives the QUIC context from the first device, the second device may transmit a response message (e.g., ACK or NACK) regarding whether the QUIC context reception was successful. At this time, if the second device does not successfully receive the QUIC context, the second device may transmit a NACK to the first device. When the first device receives a NACK from the second device, the first device may transmit the QUIC context to the second device. However, the retransmitted QUIC context may not be identical to the QUIC context transmitted at step 1725 described above. For example, each QUIC context may have a different redundancy value. At this time, the redundancy value may be a value indicating whether to retransmit the transmitted data (or the number of retransmissions). Although steps 1725 and 1730 illustrated in FIG. 17 illustrate that signaling between the first device and the second device is performed via a hotspot feeder, the QUIC context and the response to receiving the QUIC context may also be direct signaling between the first device and the second device. Accordingly, the illustration in FIG. 17 may also be intended to indicate that the IP address of the second device can be obtained via a hotspot feeder.

[0185] At step 1735, if the second device successfully receives the QUIC context from the first device (e.g., sends an ACK), the second device may transmit a probe packet (e.g., a PATH_CHALLENGE packet) to the application server via the hotspot feeder. The probe packet may include information indicating to the application server a change in endpoint (e.g., from the first device to the second device).

[0186] At step 1740, the application server may transmit a response (e.g., a PATH_RESPONSE packet) to the second device via the hotspot feeder for receiving the probe packet. The response to receiving the probe packet may be an ACK or a NACK. If the response to receiving the probe packet is an ACK, the second device receiving the ACK may not retransmit the probe packet to the application server. The application server may identify that the endpoint has changed based on the probe packet. However, the application server may also identify that the transmission path to the same endpoint (e.g., the first device) has changed.

[0187] At step 1745, the application server may send a probe packet (e.g., a PATH_CHALLENGE packet) to the second device via the hotspot feeder.

[0188] In step 1750, the second device may transmit a response regarding the success or failure of receiving the probe packet to the application server via the hotspot feeder, in the same manner as in step 1740. However, the responses in steps 1740 and 1750 may each include different information. By transmitting and / or receiving the probe packet, the application server may perform data transmission and / or reception procedures with the second device. In one embodiment, the probe packet may include information for updating a NAT (or a NAT table). The information for updating the NAT table may include information regarding changes in the connection relationship between the IP addresses of each device (e.g., the first device and the second device) and the ports of the hotspot feeder. Accordingly, the transmission / reception ports may be changed through the transmission and / or reception of the probe packet between the second device and the application server via the hotspot feeder. For example, in steps 1705 and 1710, the transmit / receive ports (e.g., I:i, H:h1) of the first device and the hotspot feeder can be changed to the transmit / receive ports (e.g., T:t, H:h2) of the second device and the hotspot feeder in steps 1735 to 1750.

[0189] At step 1755, the second device may transmit a non-search packet (e.g., a data packet) to the application server.

[0190] At step 1760, the application server may transmit non-discovery packets (e.g., data packets) to the second device. The non-discovery packets transmitted at steps 1755 and 1760 may contain data for providing metaverse services to users, and may be transmitted and / or received without passing through a hotspot feeder.

[0191] Of course, this is not limited to the above examples. The QUIC endpoint transition procedure according to the third scenario in the above-described embodiment may involve a combination or modification of some or all of the operations. Alternatively, at least one operation may be deleted or a new procedure may be added to organically combine the above-described operations.

[0192] FIG. 18 illustrates the sequence of QUIC endpoint transition operations in a third scenario according to various embodiments of the present disclosure.

[0193] Referring to FIG. 18, the operation sequence of the second device in the QUIC endpoint switching procedure according to the third scenario of FIG. 17 described above may be described. However, any description overlapping with that of FIG. 17 described above may be omitted.

[0194] At step 1810, the second device may receive a QUIC context from the first device via the hotspot feeder. At this time, the QUIC context may refer to the QUIC-SC context included in the handover request (e.g., step 1025), similar to FIG. 17 described above.

[0195] At step 1820, when the second device receives a QUIC context from the hotspot feeder, the second device may transmit a response message (e.g., ACK or NACK) to the hotspot feeder regarding whether the QUIC context reception was successful. At this time, if the second device does not successfully receive the QUIC context, the second device may transmit a NACK to the first device through the hotspot feeder. If the first device receives a NACK from the second device, the first device may transmit a QUIC context to the second device through the hotspot feeder. However, the retransmitted QUIC context may not be identical to the initially received QUIC context. For example, each QUIC context may have a different redundancy value. Alternatively, when the first device obtains the IP address of the second device (e.g., step 1720 described above), the second device may directly receive the QUIC context from the first device or directly transmit a QUIC context response to the first device.

[0196] At step 1830, if the second device successfully receives a QUIC context from the first device (e.g., transmits an ACK), the second device may transmit and / or receive a probe packet (e.g., a PATH_CHALLENGE packet) to the application server and the hotspot feeder. The probe packet may include information indicating to the application server that the endpoint has changed (e.g., from the first device to the second device). Accordingly, the application server may identify that the endpoint has changed based on the probe packet. However, the application server may also identify that the transmission path for the same endpoint (e.g., the first device) has changed. In addition, the probe packet may include information for updating a NAT table. The information for updating the NAT table may include information about a change in the connection relationship between the IP addresses of each device (e.g., the first device and the second device) and the ports of the hotspot feeder. Accordingly, the transmission / reception ports may be changed through the transmission and / or reception of the probe packet between the second device and the application server through the hotspot feeder.

[0197] At step 1840, the second device may transmit and / or receive non-navigational packets (e.g., data packets) containing data for providing metaverse services to the application server and the user. The non-navigational packets may be transmitted and / or received without passing through the hotspot feeder.

[0198] Of course, this is not limited to the above examples. Some or all of the QUIC endpoint transition operations of the second device according to the third scenario in the above-described embodiment may be combined or modified. Alternatively, at least one operation may be deleted or a new procedure may be added to organically combine with the above-described operations.

[0199] FIG. 19 illustrates the flow of signals in a QUIC endpoint switching operation in a fourth scenario according to various embodiments of the present disclosure.

[0200] Referring to FIG. 19, the operations of each device, the hotspot feeder, and the application server in the QUIC endpoint transition operation based on the fourth scenario described above can be described. At step 1905, the first device can transmit a non-discovery packet to the application server via the hotspot feeder. In this case, the non-discovery packet may refer to a data packet containing data for providing a metaverse service to a user, unlike a discovery packet transmitted to notify the application server of a change in endpoint or path.

[0201] In step 1910, the application server can transmit the non-discovery packet requested by the user to the first device via the hotspot feeder. The transmission and / or reception of the non-discovery packet between the first device and the application server in steps 1905 and 1910 described above can be performed without changing the transmission / reception ports, as it occurs before the endpoints are switched.

[0202] At step 1915, the first device may transmit the QUIC context to the application server via the hotspot feeder. In the fourth scenario, since there is no direct link between the first device and the second device and the hotspot feeder is also unreliable, the QUIC context may be transmitted from the first device to the second device via the application server. In this case, the transmitted QUIC context may refer to the QUIC-SC context included in the handover request of step 1025 described above. Accordingly, the QUIC context may include information about the QUIC connection between the first device and the application server (e.g., at least one of a connection ID, a QUIC version, a set of stream IDs, or a set of packet numbers).

[0203] At step 1920, when the application server receives a QUIC context from the first device through the hotspot feeder, it can transmit a response message (e.g., ACK) regarding the success or failure of the QUIC context reception to the second device through the hotspot feeder.

[0204] At step 1925, if the second device successfully receives the QUIC context from the application server (e.g., if an ACK is received), the second device may transmit a probe packet (e.g., a PATH_CHALLENGE packet) to the application server via the hotspot feeder. The probe packet may include information indicating to the application server a change in endpoint (e.g., from the first device to the second device).

[0205] At step 1930, the application server may transmit a response (e.g., a PATH_RESPONSE packet) to the second device via the hotspot feeder for receiving the probe packet. The response to receiving the probe packet may be an ACK or a NACK. If the response to receiving the probe packet is an ACK, the second device that received the ACK may not retransmit the probe packet to the application server. The application server may identify that the endpoint has changed based on the probe packet. However, the application server may also identify that the transmission path to the same endpoint (e.g., the first device) has changed.

[0206] At step 1935, the application server may send a probe packet (e.g., a PATH_CHALLENGE packet) to the second device via the hotspot feeder.

[0207] In step 1940, the second device may transmit a response regarding the success or failure of receiving the probe packet to the application server via the hotspot feeder, in the same manner as in step 1930. However, the responses in steps 1930 and 1940 may each include different information. By transmitting and / or receiving the probe packet, the application server may perform data transmission and / or reception procedures with the second device. In one embodiment, the probe packet may include information for updating a NAT (or a NAT table). The information for updating the NAT table may include information regarding changes in the connection relationship between the IP addresses of each device (e.g., the first device and the second device) and the ports of the hotspot feeder. Therefore, when transmitting and / or receiving probe packets between the second device and the application server via the hotspot feeder, the transmission / reception ports may change depending on the switching of the endpoints. For example, in steps 1905 and 1910, the transmit / receive ports (e.g., I:i, H:h1) of the first device and the hotspot feeder can be changed to the transmit / receive ports (e.g., T:t, H:h2) of the second device and the hotspot feeder in steps 1925 to 1940.

[0208] At step 1945, the second device may transmit a non-search packet (e.g., a data packet) to the application server.

[0209] At step 1950, the application server may transmit non-discovery packets (e.g., data packets) to the second device. The non-discovery packets transmitted at steps 1945 and 1950 may contain data for providing metaverse services to users, and may be transmitted and / or received without passing through a hotspot feeder.

[0210] Of course, this is not limited to the above examples. The QUIC endpoint transition procedure according to the fourth scenario in the above-described embodiment may involve a combination or modification of some or all of the operations. Alternatively, at least one operation may be deleted or a new procedure may be added to organically combine the above-described operations.

[0211] FIG. 20 illustrates the sequence of QUIC endpoint transition operations in a fourth scenario according to various embodiments of the present disclosure.

[0212] Referring to FIG. 20, the operation sequence of the second device in the QUIC endpoint switching procedure according to the fourth scenario of FIG. 19 described above may be described. However, any description overlapping with that of FIG. 19 described above may be omitted.

[0213] At step 2010, the second device may receive a QUIC context from the application server via the hotspot feeder. At this time, the QUIC context may refer to the QUIC-SC context included in the handover request (e.g., step 1025), as in FIG. 19 described above.

[0214] In step 2020, if the second device successfully receives the QUIC context (e.g., if an ACK is received), the second device may transmit and / or receive a probe packet (e.g., a PATH_CHALLENGE packet) through the application server and the hotspot feeder. The probe packet may include information indicating to the application server that the endpoint has changed (e.g., from the first device to the second device). Accordingly, the application server may identify that the endpoint has changed based on the probe packet. However, the application server may also identify that the transmission path for the same endpoint (e.g., the first device) has changed. In addition, the probe packet may include information for updating a NAT table. The information for updating the NAT table may include information about a change in the connection relationship between the IP address of each device (e.g., the first device and the second device) and the port of the hotspot feeder. Therefore, when transmitting and / or receiving a discovery packet between a second device and an application server through a hotspot feeder, the transmitting / receiving port may change depending on the switching of the endpoint.

[0215] At step 2030, the second device may transmit and / or receive non-navigational packets (e.g., data packets) containing data for providing metaverse services to the application server and the user. The non-navigational packets may be transmitted and / or received without passing through the hotspot feeder.

[0216] Of course, this is not limited to the above examples. Some or all of the QUIC endpoint transition operations of the second device according to the fourth scenario in the above-described embodiment may be combined or modified. Alternatively, at least one operation may be deleted or a new procedure may be added to organically combine with the above-described operations.

[0217] FIG. 21 illustrates a concept of a handover procedure according to various embodiments of the present disclosure.

[0218] Referring to FIG. 21, an embodiment for applying the QUIC-SC method of FIG. 10 described above when a terminal performs a handover in a 3GPP wireless communication system can be described. Specifically, QUIC can be applied to a user plane (UP) in a QUIC-based wireless communication system (e.g., a 6G communication system). When a terminal performs a handover, a QUIC endpoint (e.g., a base station (gNB)) may need to be switched. At this time, a handover request transmitted by the terminal to a source base station (e.g., a first base station or RAN 1) may include a QUIC-SC context with the same or similar intent as the handoff request in step 1025 described above. At this time, the handoff request is only one example, and may be included in another message or only a manifest may be transmitted. The transmitted QUIC-SC context may be transmitted through an X2 interface between a source base station and a target base station (e.g., a second base station or RAN 2). Therefore, when the terminal is handed over, the continuity of the terminal's PDU session connection can be guaranteed. The UPF can play the role of a reliable hotspot feeder in the second scenario described above (e.g., FIGS. 15 and 16). For example, the source base station and the target base station can be connected to the application server through the UPF. This may be because the 3GPP network is configured as a reliable network through IP security. However, the UPF can also play a role similar to the UPF (170) of FIG. 1 described above, in addition to the relay role of the hotspot feeder described above. In this case, the UPF can be a network entity that provides the same function as the UPF (170) of FIG. 2 described above, and can support the QUIC protocol. In addition, the UPF can be connected to each of the source base station and the target base station through a QUIC-based flow.

[0219] The QUIC-SC context transmitted from the source base station to the target base station may include at least one of a connection ID, a QUIC version, a set of stream IDs, or a set of packet numbers. The QUIC-SC context may refer to a set of metadata required to continue the QUIC connection as is, with the same or similar intent as described in FIG. 11 described above. However, the QUIC-SC context transmitted from the source base station to the target base station may have at least one piece of information excluded or added to the example of FIG. 11. In addition, the QUIC-SC context manifest (or manifest) may mean a normalized method, structure, or field for expressing metadata with the same or similar intent as described in FIG. 11 described above. However, the QUIC-SC context manifest may not necessarily have the same structure as that illustrated in FIG. 11 described above, and the structure of the QUIC-SC context manifest may be modified for application to a 3GPP communication system. Of course, Fig. 21 is only one example, and the QUIC-SC context manifest in a 3GPP communication system is not limited to the example in Fig. 21.

[0220] FIG. 22 illustrates the flow of signals in a handover procedure according to various embodiments of the present disclosure.

[0221] Referring to FIG. 22, the operations of a source base station (hereinafter referred to as a first base station), a target base station (hereinafter referred to as a second base station), and a UPF may be described based on a handover scenario in a QUIC-based wireless communication system (e.g., a 6G communication system) of FIG. 21 described above. The handover scenario may include some or all of the handover procedures in a 3GPP communication system. In addition, the handover scenario may further include a QUIC-SC context transfer operation through an X2 interface between base stations.

[0222] At step 2205, the first base station may transmit a non-probing packet to the UPF. At this time, the non-probing packet may refer to a data packet containing data to be provided to the terminal, unlike a probing packet transmitted to the UPF to notify a path switching (e.g., a change in the serving base station due to a handover).

[0223] At step 2210, the UPF is before the path change, so it can transmit the non-discovery packet requested by the user to the first base station.

[0224] At step 2215, the first base station may transmit a QUIC context to the second device. At this time, the transmitted QUIC context may refer to the QUIC-SC context illustrated in FIG. 21 described above. Accordingly, the QUIC context may include information about the QUIC connection between the first base station and the UPF (e.g., at least one of a connection ID, a QUIC version, a set of stream IDs, or a set of packet numbers).

[0225] In step 2220, when the second base station receives the QUIC context from the first base station, the second base station may transmit a response message (e.g., ACK or NACK) regarding whether the QUIC context reception was successful. At this time, if the second base station does not successfully receive the QUIC context, it may transmit a NACK to the first base station. If the first base station receives a NACK from the second base station, it may transmit the QUIC context to the second base station. However, the retransmitted QUIC context may not be identical to the QUIC context transmitted in step 2215 described above. For example, each QUIC context may have a different redundancy value. At this time, the redundancy value may be a value indicating whether to retransmit the transmitted data (or the number of retransmissions).

[0226] At step 2225, after the second base station receives the QUIC context from the first base station, the UPF may send a path change request to the second base station.

[0227] At step 2230, the UPF may transmit data including an end marker to the first base station. The end marker may be a packet intended to prevent packet loss or packet ordering from changing during the traffic flow transition from the first base station to the second base station. Furthermore, the data transmitted by the UPF may include at least one end marker.

[0228] At step 2235, the first base station can transmit data including the end marker received from the UPF at step 2230 to the second base station. The second base station, having received the end marker from the first base station, can identify that packets to be transmitted to the terminal are no longer transmitted through the first base station.

[0229] At step 2240, the second base station may transmit a response to the path change request to the UPF upon receiving the end marker. The response to the path change request may include information indicating that the path change has been completed.

[0230] At step 2245, the second base station may transmit a probing packet (e.g., a PATH_CHALLENGE packet) to the UPF. The probing packet may instruct the UPF to change the path (e.g., change the serving base station from the first base station to the second base station).

[0231] At step 2250, the UPF may transmit a response (e.g., a PATH_RESPONSE packet) to the second base station for receiving the probe packet. The response to receiving the probe packet may be an ACK or a NACK. If the response to receiving the probe packet is an ACK, the second base station that received the ACK may not retransmit the probe packet to the UPF.

[0232] At step 2255, the UPF may transmit a discovery packet (e.g., a PATH_CHALLENGE packet) to the second base station.

[0233] In step 2260, the second base station may transmit a response to the UPF regarding the success or failure of the probe packet reception, in the same manner as in step 2250. However, the responses in steps 2250 and 2260 may each include different information. By transmitting and / or receiving the probe packet, the UPF may perform data transmission and / or reception procedures with the second base station.

[0234] At step 2265, the second base station may transmit a non-discovery packet (e.g., a data packet) to the UPF.

[0235] In step 2270, the UPF may transmit non-discovery packets (e.g., data packets) to the second base station. The non-discovery packets transmitted in steps 2265 and 2270 may include data for providing communication services to the terminal.

[0236] Of course, the above examples are not limited. The handover procedure in the above-described embodiments may involve a combination or modification of some or all of the operations. Alternatively, at least one operation may be deleted or a new procedure may be added to organically combine the above-described operations.

[0237] FIG. 23 illustrates the operation sequence of a target base station in a handover procedure according to various embodiments of the present disclosure.

[0238] Referring to FIG. 23, the operation sequence of the second base station in the handover procedure in the QUIC-based wireless communication system (e.g., 6G communication system) of FIG. 22 described above may be described. However, any description overlapping with that of FIG. 22 described above may be omitted.

[0239] At step 2310, the second base station may receive a QUIC context from the first device. At this time, the received QUIC context may refer to the QUIC-SC context illustrated in FIG. 21 described above. Accordingly, the QUIC context may include information about a QUIC connection between the first base station and the UPF (e.g., at least one of a connection ID, a QUIC version, a set of stream IDs, or a set of packet numbers).

[0240] In step 2320, when the second base station receives a QUIC context from the first base station, the second base station may transmit a response message (e.g., ACK or NACK) to the first base station regarding whether the QUIC context reception was successful. At this time, if the second base station does not successfully receive the QUIC context, it may transmit a NACK to the first base station. If the first base station receives a NACK from the second base station, it may transmit the QUIC context to the second base station. However, the retransmitted QUIC context may not be identical to the QUIC context transmitted in step 2310 described above. For example, each QUIC context may have a different redundancy value. At this time, the redundancy value may be a value indicating whether to retransmit the transmitted data (or the number of retransmissions).

[0241] At step 2330, after receiving a QUIC context from the first base station, the second base station may receive a path change request from the UPF.

[0242] At step 2340, the second base station may receive data from the first base station, including an end marker. The end marker may be a packet intended to prevent packet loss or reordering during the traffic flow transition from the first base station to the second base station. Furthermore, data transmitted by the UPF may include at least one end marker.

[0243] At step 2350, the second base station may transmit a response to the path change request to the UPF upon receiving the end marker. The response to the path change request may include information indicating that the path change has been completed.

[0244] At step 2360, the second base station may transmit and receive a UPF and a probing packet (e.g., a PATH_CHALLENGE packet). At this time, the probing packet may instruct the UPF to change the path (e.g., change the serving base station from the first base station to the second base station).

[0245] At step 2370, the second base station can transmit and receive UPF and non-discovery packets (e.g., data packets). At this time, the non-discovery packets can include data for providing communication services to the terminal.

[0246] Of course, the above examples are not limited. Some or all of the handover operations in the above-described embodiments may be combined or modified. Alternatively, at least one operation may be deleted or a new procedure may be added to organically combine with the above-described operations.

[0247] Or at least one action may be deleted or a new procedure may be added and organically combined with the actions described above.

[0248] FIG. 24 illustrates an operation sequence of a target device according to various embodiments of the present disclosure.

[0249] Referring to FIG. 24, a transfer operation of a QUIC-SC context between devices (e.g., devices providing a metaverse service) according to the first or second scenario described in FIGS. 13 to 16 described above may be described. In the following embodiments of the present disclosure, the first device may be a device that will receive a QUIC session from a second device (or a device that will receive a metaverse service after a QUIC endpoint is changed). In addition, the second device may be a device that previously provided a metaverse service using a QUIC session (or a device that was providing a metaverse service before the QUIC endpoint was changed). Therefore, both the first device and the second device may be any devices that can provide a metaverse service.

[0250] At step 2410, the first device may receive a QUIC-SC context from the second device. At this time, the QUIC-SC context may refer to the QUIC-SC context included in the handover request (e.g., step 1025), similar to FIG. 13 described above.

[0251] At step 2420, the first device may transmit a response to the reception of the QUIC-SC context received from the second device to the second device. For example, the response message may include an ACK or a NACK. If the first device does not successfully receive the QUIC context, it may transmit a NACK to the second device. If the second device receives a NACK from the first device, it may transmit a QUIC context to the first device. However, the retransmitted QUIC context may not be identical to the QUIC context received at step 2410 described above. For example, each QUIC context may have a different redundancy value. If the first device successfully receives the QUIC context from the second device (e.g., if it transmits an ACK to the second device), it may transmit and / or receive a discovery packet (e.g., a PATH_CHALLENGE packet) to and from the application server. At this time, the discovery packet may include information indicating to the application server that the endpoint has changed (e.g., from a second device to a first device). Therefore, the application server can identify that the endpoint has changed based on the discovery packet. However, the application server may also identify that the transmission path to the same endpoint (e.g., the second device) has changed. Thereafter, the first device may transmit and / or receive non-discovery packets (e.g., data packets) containing data for providing metaverse services to the application server and the user.

[0252] Of course, this is not limited to the above examples. Some or all of the QUIC endpoint transition operations described above may be combined or modified. Alternatively, at least one operation may be deleted or a new procedure may be added to organically combine with the operations described above.

[0253] A method of a first device in a communication system supporting a QUIC (quick user datagram protocol (UDP) internet connections) protocol according to one embodiment of the present disclosure, comprising the steps of receiving a QUIC-SC (service continuity) context from a second device, and transmitting a response to the reception of the QUIC-SC context to the second device, wherein, based on the QUIC-SC context, an endpoint change of a QUIC connection to an application server is identified, and the endpoint change of the QUIC connection may include a migration of the QUIC connection from the second device to the first device.

[0254] In one embodiment, the method further includes a step of transmitting information for updating a network address translation (NAT) table to the application server via a network providing device, wherein the NAT table includes a mapping relationship between identification information of each of the first device and the second device and an internet protocol (IP), and the information for updating the NAT table may include change information for a connection relationship between an IP of each of the first device and the second device and a port of the network providing device.

[0255] In one embodiment, the QUIC-SC context includes at least one of a connection identifier, a QUIC version, a set of stream identifiers, or a set of packet numbers, and a QUIC-SC context manifest includes the QUIC-SC context, and the QUIC-SC context manifest may be a normalized structure of information included in the QUIC-SC context.

[0256] In one embodiment, each of the first device and the second device is a device that supports an Internet-based application service by being connected to an application server via a wireless network, and each of the first device and the second device can be connected to the application server via the QUIC protocol.

[0257] In one embodiment, the first device and the second device are base stations connected to each other via an X2 interface, and the QUIC-SC context may be included in a handover request.

[0258] In a method of a network providing device in a communication system supporting a QUIC (quick UDP (user datagram protocol) internet connections) protocol according to one embodiment of the present disclosure, the method comprises receiving a QUIC context from a second device, wherein a first device and the second device are devices that are connected to an application server via a wireless network and support an internet-based application service, and wherein each of the first device and the second device is connected to the application server via the QUIC protocol, and based on the QUIC-SC context, an endpoint change of a QUIC connection to the application server is identified, and the endpoint change of the QUIC connection may include a migration of the QUIC connection from the second device to the first device.

[0259] In one embodiment, the method further comprises the steps of receiving a request for information for identifying the first device from the second device, and transmitting a response to the request including an Internet protocol (IP) of the first device to the second device, wherein the first device and the second device may each be devices connected to the same user account.

[0260] In one embodiment, the method further comprises the steps of transmitting the QUIC-SC context to the application server, and transmitting a response to the QUIC-SC context received from the application server to the first device, wherein the first device and the second device may be devices connected to different user accounts.

[0261] In one embodiment, the method further includes a step of transmitting information for updating a network address translation (NAT) table received from the first device to the application server, wherein the NAT table includes a mapping relationship between identification information of each of the first device and the second device and an IP (internet protocol), and the information for updating the NAT table may include change information for a connection relationship between an IP of each of the first device and the second device and a port of the network providing device.

[0262] In one embodiment, the QUIC-SC context includes at least one of a connection identifier, a QUIC version, a set of stream identifiers, or a set of packet numbers, and a QUIC-SC context manifest includes the QUIC-SC context, and the QUIC-SC context manifest may be a normalized structure of information included in the QUIC-SC context.

[0263] In a communication system supporting a QUIC (quick user datagram protocol (UDP) internet connections) protocol according to one embodiment of the present disclosure, a first device comprises a transceiver, and at least one control unit coupled to the transceiver, wherein the at least one control unit receives a QUIC-SC (service continuity) context from a second device, and transmits a response to reception of the QUIC-SC context to the second device, and based on the QUIC-SC context, an endpoint change of a QUIC connection to an application server is identified, and the endpoint change of the QUIC connection may include migration of the QUIC connection from the second device to the first device.

[0264] In one embodiment, the at least one control unit transmits information for updating a network address translation (NAT) table to the application server via a network providing device, and the information for updating the NAT table may include information for changing a connection relationship between an IP (internet protocol) of each of the first device and the second device and a port of the network providing device.

[0265] In one embodiment, the QUIC-SC context includes at least one of a connection identifier, a QUIC version, a set of stream identifiers, or a set of packet numbers, and a QUIC-SC context manifest includes the QUIC-SC context, and the QUIC-SC context manifest may be a normalized structure of information included in the QUIC-SC context.

[0266] In one embodiment, each of the first device and the second device is a device that supports an Internet-based application service by being connected to an application server via a wireless network, and each of the first device and the second device can be connected to the application server via the QUIC protocol.

[0267] In one embodiment, the first device and the second device are base stations connected to each other via an X2 interface, and the QUIC-SC context may be included in a handover request.

[0268] In a communication system supporting a QUIC (quick UDP (user datagram protocol) internet connections) protocol according to one embodiment of the present disclosure, a network providing device comprises a transceiver, and at least one control unit coupled to the transceiver, wherein the at least one control unit receives a QUIC context from a second device, and each of the first device and the second device is connected to an application server via a wireless network and is a device supporting an internet-based application service, and each of the first device and the second device is connected to the application server via the QUIC protocol, and based on the QUIC-SC context, an endpoint change of a QUIC connection to an application server is identified, and the endpoint change of the QUIC connection may include a migration of the QUIC connection from the second device to the first device.

[0269] In one embodiment, the at least one control unit receives a request for information for identifying the first device from the second device, and transmits a response to the request including an IP (internet protocol) of the first device to the second device, wherein the first device and the second device may each be devices connected to the same user account.

[0270] In one embodiment, the at least one control unit transmits the QUIC-SC context to the application server and transmits a response to the QUIC-SC context received from the application server to the first device, wherein the first device and the second device may be devices connected to different user accounts.

[0271] In one embodiment, the at least one control unit transmits information for updating a network address translation (NAT) table received from the first device to the application server, and the information for updating the NAT table may include information for changing a connection relationship between an IP (internet protocol) of each of the first device and the second device and a port of the network providing device.

[0272] In one embodiment, the QUIC-SC context includes at least one of a connection identifier, a QUIC version, a set of stream identifiers, or a set of packet numbers, and a QUIC-SC context manifest includes the QUIC-SC context, and the QUIC-SC context manifest may be a normalized structure of information included in the QUIC-SC context.

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

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

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

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

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

[0278] 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 of a first device in a communication system supporting QUIC (quick UDP (user datagram protocol) internet connections) protocol, A step of receiving a QUIC-SC (service continuity) context from a second device; and A step of transmitting a response to the reception of the QUIC-SC context to the second device, Based on the above QUIC-SC context, the endpoint change of the QUIC connection to the application server is identified, A method wherein changing the endpoint of the QUIC connection comprises migrating the QUIC connection from the second device to the first device.

2. In claim 1, the method comprises: Further comprising the step of transmitting information for updating a NAT (network address translation) table to the application server via a network providing device, The above NAT table includes the identification information of each of the first device and the second device and the mapping relationship of IP (internet protocol), A method, wherein the information for updating the NAT table includes information on changes in the connection relationship between the IP of each of the first device and the second device and the port of the network providing device.

3. In claim 1, The above QUIC-SC context includes at least one of a connection identifier, a QUIC version, a set of stream identifiers, or a set of packet numbers, The QUIC-SC context manifest contains the above QUIC-SC context, A method wherein the above QUIC-SC context manifest is a normalized structure of information included in the above QUIC-SC context.

4. In claim 1, Each of the above first device and the above second device is a device that is connected to an application server via a wireless network and supports an Internet-based application service. A method, wherein each of the first device and the second device is connected to the application server via the QUIC protocol.

5. In a method of a network providing device in a communication system supporting QUIC (quick UDP (user datagram protocol) internet connections) protocol, A step of receiving a QUIC-SC context from a second device, The first device and the second device are each connected to an application server via a wireless network and are devices that support Internet-based application services. Each of the first device and the second device is connected to the application server via the QUIC protocol, Based on the above QUIC-SC context, the endpoint change of the QUIC connection to the application server is identified, A method wherein changing the endpoint of the QUIC connection comprises migrating the QUIC connection from the second device to the first device.

6. In claim 5, the method comprises: A step of receiving a request for information for identifying the first device from the second device; and Further comprising the step of transmitting a response to the request including the IP (internet protocol) of the first device to the second device, A method, wherein the first device and the second device are each connected to the same user account.

7. In claim 5, the method comprises: a step of transmitting the QUIC-SC context to the application server; and Further comprising the step of transmitting a response to the QUIC-SC context received from the application server to the first device, A method wherein the first device and the second device are devices connected to different user accounts.

8. In claim 5, the method comprises: Further comprising a step of transmitting information for updating a NAT (network address translation) table received from the first device to the application server, The above NAT table includes the identification information of each of the first device and the second device and the mapping relationship of IP (internet protocol), A method, wherein the information for updating the NAT table includes information on changes in the connection relationship between the IP of each of the first device and the second device and the port of the network providing device.

9. As the first device in a communication system supporting the QUIC (quick UDP (user datagram protocol) internet connections) protocol, Transmitter and receiver; and At least one control unit coupled to the above transceiver unit, At least one of the above control units: Receive a QUIC-SC (service continuity) context from a second device, is set to transmit a response to the reception of the QUIC-SC context to the second device; Based on the above QUIC-SC context, the endpoint change of the QUIC connection to the application server is identified, A first device, wherein the change of the endpoint of the QUIC connection comprises a migration of the QUIC connection from the second device to the first device.

10. In claim 9, at least one control unit: It is further configured to transmit information for updating a network address translation (NAT) table to the application server via a network providing device, The above NAT table includes the identification information of each of the first device and the second device and the mapping relationship of IP (internet protocol), A first device, wherein the information for updating the NAT table includes information on changes in the connection relationship between the IP (internet protocol) of each of the first device and the second device and the port of the network providing device.

11. In claim 9, The above QUIC-SC context includes at least one of a connection identifier, a QUIC version, a set of stream identifiers, or a set of packet numbers, The QUIC-SC context manifest contains the above QUIC-SC context, A first device, wherein the QUIC-SC context manifest is a normalized structure of information included in the QUIC-SC context.

12. In claim 9, Each of the above first device and the above second device is a device that is connected to an application server via a wireless network and supports an Internet-based application service. A first device, wherein each of the first device and the second device is connected to the application server via the QUIC protocol.

13. As a network providing device in a communication system supporting the QUIC (quick UDP (user datagram protocol) internet connections) protocol, Transmitter and receiver; and At least one control unit coupled to the above transceiver unit, At least one of the above control units: It is set to receive a QUIC-SC context from a second device, The first device and the second device are each connected to an application server via a wireless network and are devices that support Internet-based application services. Each of the first device and the second device is connected to the application server via the QUIC protocol, Based on the above QUIC-SC context, the endpoint change of the QUIC connection to the application server is identified, A network providing device, wherein the change of the endpoint of the QUIC connection comprises a migration of the QUIC connection from the second device to the first device.

14. In claim 13, the at least one control unit: Receive a request for information for identifying said first device from said second device, and Further set to transmit a response to the request including the IP (internet protocol) of the first device to the second device, A network providing device, wherein the first device and the second device are each connected to the same user account.

15. In claim 13, the at least one control unit: Send the QUIC-SC context to the application server, and It is further configured to transmit a response to the QUIC-SC context received from the application server to the first device, A network providing device, wherein the first device and the second device are devices connected to different user accounts.

Images