KR20240078930A - Method for guaranteeing 6g end-to-end application-level latency using network transport api and electronic device - Google Patents

Abstract

A method for an electronic device to transmit an application service between end-to-end networks according to the present invention includes the steps of calling an API function from an application layer and providing raw data to an encoder of a lower layer; The encoder receiving information about network status (NS) from a socket; The encoder encoding the raw data based on information about the NS and providing an encoded application data unit (ADU) to the socket; The socket transmits the ADU to a transport layer; And it may include transmitting the ADU to a network through the transport layer.

Description

Method for ensuring 6G end-to-end application-level delay using network transport API and electronic device therefor {METHOD FOR GUARANTEEING 6G END-TO-END APPLICATION-LEVEL LATENCY USING NETWORK TRANSPORT API AND ELECTRONIC DEVICE}

The present invention relates to a method for ensuring 6G end-to-end application-level delay, and more specifically, to a method for ensuring 6G end-to-end application-level delay using a network transmission API and an electronic device therefor.

The three key service requirements for 5G are (1) Enhanced Mobile Broadband (eMBB) services, (2) massive Machine Type Communication (mMTC) services, and (3) ultra-reliability. and ultra-reliable and low latency communications (URLLC) services. Some use cases may require multiple areas for optimization, while others may focus on just one Key Performance Indicator (KPI). 5G supports these diverse use cases in a flexible and reliable way.

5G will also be used for remote work in the cloud and will require much lower end-to-end latency to maintain a good user experience when tactile interfaces are used. For example, cloud gaming and video streaming are other key factors driving increased demand for mobile broadband capabilities. Entertainment is essential on smartphones and tablets anywhere, including high mobility environments such as trains, cars and airplanes. Another use case is augmented reality for entertainment and information retrieval. Here, augmented reality requires very low latency and instantaneous amounts of data.

URLLC in 5G and 6G communications includes new services that will transform the industry through ultra-reliable/low-latency links, such as remote control of critical infrastructure and self-driving vehicles, and end-to-end ultra-precision networking. This level of reliability and latency is essential for 6G end-to-end ultra-precision networking, smart grid control, industrial automation, robotics, and drone control and coordination.

In order to expand these services requiring ultra-low delay and enable ultra-precision transmission and end-to-end on-time transmission, a method for guaranteeing application-level delay for application services is required. However, in conventional electronic devices, the existing socket structure cannot transmit information between the application layer and the transport layer, making it impossible to guarantee application-level delay. Accordingly, the present invention seeks to solve this problem and propose a method for end-to-end application-level delay guarantee (application-level on-time transmission guarantee) in next-generation communications such as 6G.

Korean Patent Publication No. 10-2267420

The technical problem to be achieved by the present invention is to provide a method for electronic devices to transmit application services between end-to-end networks.

Another technical problem to be achieved by the present invention is to provide an electronic device that transmits application services between end-to-end networks.

The technical problems to be achieved in the present invention are not limited to the above technical problems, and other technical problems not mentioned will be clearly understood by those skilled in the art from the description below.

In order to achieve the above technical problem, a method of transmitting an application service between end-to-end networks by an electronic device according to the present invention includes the steps of calling an API function from an application layer and providing raw data to an encoder of a lower layer; The encoder receiving information about network status (NS) from a socket; The encoder encoding the raw data based on information about the NS and providing an encoded application data unit (ADU) to the socket; The socket transmits the ADU to a transport layer; And it may include transmitting the ADU to a network through the transport layer.

The information about the NS may include at least one of information about network congestion, information about wireless channel status of the network, and information about resource allocation in the network. Among the information about the NS, information about the wireless channel status of the network and resource allocation information in the network may be received from the network. Information about the wireless channel status of the network may include information about the required compression rate of the raw data for end-to-end on-time transmission of the application service. Information about resource allocation in the network may include information about a compression rate that enables on-time end-to-end transmission using the maximum available resources.

The encoder can determine the size of the ADU based on information about the NS. The API function is a predefined Application-level Latency Guarantee (ALG) function and may include the raw data argument. When the ALG function includes only the raw data transfer factor, the encoder determines the target application latency (Application latency, Even if it arrives before or after the AL) value and the target AL, the allowable tolerance value is recognized and processed as a predefined default value.

The API function is a predefined Application-level Latency Guarantee (ALG) function, and in addition to the raw data transfer argument, it includes an edge server identifier transfer argument, a target application latency transfer argument, and the target application delay time. Even if it arrives before or after, at least one of the allowable tolerance transfer factors can be included. In the step of providing raw data to the encoder, at least one of information about the edge server identifier, the target application delay time, and the tolerance is further provided to the encoder. The encoder further encodes the ADU based on at least one of information about the edge server identifier, the target application delay time, and the tolerance.

In order to achieve the above-described other technical problems, an electronic device for transmitting an application service between end-to-end networks according to the present invention provides raw data to the encoder of the lower layer by calling an API function in the application layer, and provides raw data to the encoder of the lower layer. Information about network status (NS) is provided to the encoder, and the encoder encodes the raw data based on the information about the NS to produce an encoded application data unit (ADU). A socket module configured to provide a socket and allow the socket to transmit the ADU to a transport layer; And it may include a processor that controls the ADU to be transmitted to the network.

The electronic device may further include an RF unit for transmitting information such as the ADU to a network.

In the socket module, the encoder can determine the size of the ADU based on information about the NS.

The API function is a predefined Application-level Latency Guarantee (ALG) function, and when it includes only the raw data transfer argument, the encoder in the socket module transmits the raw data to the ALG function. The target application latency (AL) value for which transmission completion is desired to be guaranteed from the time of the call to the application layer of the destination end, and the default tolerance value that is allowed even if it arrives before or after the target AL are predefined. It is recognized and processed as a (default) value.

The API function is a predefined Application-level Latency Guarantee (ALG) function, and in addition to the raw data transfer argument, it includes an edge server identifier transfer argument, a target application latency transfer argument, and the target application delay time. It further includes at least one of a tolerance transfer factor that is allowed even if it arrives before or after, and the encoder in the socket module further considers at least one of the edge server identifier, the target application delay time, and information about the tolerance. The raw data is encoded to generate an ADU.

According to the network end-to-end transmission method of application services according to the present invention, 6G end-to-end application level delay performance is guaranteed, enabling ultra-precise and on-time transmission of ultra-sensitive application services from the application layer at the source end to the application layer at the destination end. It becomes.

The electronic device that performs the network end-to-end transmission method of application services according to the present invention includes a socket module (New Socket), allowing application developers to freely develop application services without considering the data size and network conditions in the application layer. The effect of providing an environment occurs.

The effects that can be obtained from the present invention are not limited to the effects mentioned above, and other effects not mentioned can be clearly understood by those skilled in the art from the description below. will be.

The accompanying drawings, which are included as part of the detailed description to aid understanding of the present invention, provide embodiments of the present invention, and together with the detailed description, explain the technical idea of the present invention.
Figure 1 is a diagram showing the overall system structure of 5G NR.
Figure 2 is a diagram showing the logical architecture in an Open RAN (O-RAN) system.
Figure 3 is a diagram to explain latency for each service/application.
Figure 4 is a diagram illustrating the protocol stack-user plane of 5G, 6G, etc.
Figure 5 is a diagram illustrating the 6G end-to-end network structure.
FIG. 6 is a diagram showing the configuration of an electronic device 600 at the end that can be applied to embodiments of the present invention.
FIG. 7 is a diagram illustrating the structure of the socket module 620 of the electronic device 600 proposed by the present invention for on-time transmission of 6G end-to-end application services and the operation of the electronic device 600.
Figure 8 is a diagram illustrating the overall network architecture required for on-time transmission of 6G end-to-end application services according to the present invention.
Figure 9 is a diagram illustrating signaling information required in the network for on-time transmission of the 6G end-to-end application service according to the present invention.

Hereinafter, preferred embodiments according to the present invention will be described in detail with reference to the attached drawings. The detailed description set forth below in conjunction with the accompanying drawings is intended to illustrate exemplary embodiments of the invention and is not intended to represent the only embodiments in which the invention may be practiced. The following detailed description includes specific details to provide a thorough understanding of the invention. However, one skilled in the art will appreciate that the present invention may be practiced without these specific details. For example, for convenience of explanation, the detailed description below assumes that the mobile communication system is 3GPP 5G NR, the next-generation communication system 6G, and Open RAN (O-RAN) system. However, 3GPP 5G NR, Except for issues specific to the next-generation communication system, 6G and Open RAN (O-RAN), it can also be applied to any other mobile communication system.

In some cases, in order to avoid ambiguity of the concept of the present invention, well-known structures and devices may be omitted or may be shown in block diagram form focusing on the core functions of each structure and device. In addition, the same components are described using the same reference numerals throughout this specification.

In addition, in the following description, the electronic device may include a mobile terminal or a fixed user device such as a terminal capable of 6G communication (e.g., User Equipment (UE), Mobile Station (MS)). In addition, it is assumed that the base station collectively refers to any node on the network that communicates with the terminal, such as Node B, gNode B, eNode B, Base Station, or AP (Access Point). The terminal can receive information from the base station/network through the downlink, and the terminal can also transmit information to the base station/network through the uplink. Information transmitted or received by the terminal includes data and various control information, and various physical channels exist depending on the type and purpose of the information transmitted or received by the terminal.

In addition, specific terms used in the following description are provided to aid understanding of the present invention, and the use of such specific terms may be changed to other forms without departing from the technical spirit of the present invention.

5G NR (new radio) defines eMBB (enhanced Mobile Broadband), mMTC (massive Machine Type Communications), URLLC (Ultra-Reliable and Low Latency Communications), and V2X (vehicle-to-everything) depending on the usage scenario. Additionally, the 5G NR standard is divided into standalone (SA) and non-standalone (NSA) depending on the co-existence between the NR system and the LTE system. Additionally, 5G NR supports various subcarrier spacings and supports CP-OFDM in the downlink and CP-OFDM and DFT-s-OFDM (SC-OFDM) in the uplink.

Embodiments of the present invention can be supported by standard documents disclosed for wireless access systems such as 5G NR, 6G, and Open RAN. That is, among the embodiments of the present invention, steps or parts not described in order to clearly reveal the technical idea of the present invention may be supported by the above documents. Additionally, all terms disclosed in this document can be explained by the standard documents.

In the present invention, we propose a method for ultra-precision networking and the concept of an application programming interface (API) for ultra-precision network transmission in end-end electronic devices to ensure end-to-end application-level delay in 6G, the next-generation communication system.

The present invention can be applied not only to 6G, but also to 3GPP 5G and Open RAN, which are currently being standardized. First, we will briefly explain the 5G NR and Open RAN systems to which the method proposed in this specification can be applied and then describe the present invention.

Figure 1 is a diagram showing the overall system structure of 5G NR.

Referring to Figure 1, NG-RAN is a base station (gNB) that provides NG-RA user plane (new AS sublayer/PDCP/RLC/MAC/PHY) and control plane (RRC) protocol termination for user equipment (UE). It consists of gNBs are interconnected via the Xn interface. gNB is also connected to NGC through the NG interface. The gNB is connected to the Access and Mobility Management Function (AMF) through the N2 interface and to the User Plane Function (UPF) through the N3 interface.

NG-C represents the control plane interface used for the NG2 reference point between the new RAN and NGC, and NG-U represents the user plane interface used for the NG3 reference point between the new RAN and NGC. indicates. Non-standalone NR has a deployment configuration in which the gNB requires an LTE eNB as an anchor for the control plane connection to the EPC or an eLTE eNB as an anchor for the control plane connection to the NGC. Non-standalone E-UTRA: The eLTE eNB has a deployment configuration that requires a gNB as an anchor for control plane connectivity to the NGC. The user plane gateway is the endpoint of the NG-U interface.

In the 5G system, the radio unit (RU) is a device that processes the digital front end (DFE), part of the PHY layer, and digital beamforming functions. 5G RU design must be inherently intelligent, but key considerations for RU design are size, weight, and power consumption. The Distributed Unit (DU) is a distributed processing unit located close to the RU and runs parts of the RLC, MAC, and PHY layers. This logical node contains a subset of eNB/gNB functions depending on the functional splitting option and its operation is controlled by a Centralized Unit (CU). DUs can be distributed unit software deployed on-site on COTS servers, DU software is typically deployed near RUs on-site and can run parts of the RLC, MAC, and PHY layers.

CU is a centralized unit that runs RRC and PDCP layers. The gNB consists of a CU and one DU connected to the CU via Fs-C and Fs-U interfaces to CP and UP, respectively. A CU with multiple DUs supports multiple gNBs. The split architecture allows 5G networks to utilize different deployments of the protocol stack between CUs and DUs depending on the intermediate availability and network design. It is a logical node that includes gNB functions such as user data transmission, mobility control, RAN sharing (MORAN), positioning, session management, etc. However, functions allocated only to DU are an exception. The CU controls the operation of multiple DUs through the midhaul interface. The central device, CU, mainly includes RRC, SDAP and PDCP protocol layers and is mainly responsible for non-real-time RRC and PDCP protocol stack functions. CU can be deployed in the cloud to support integrated deployment of core network UPF sinking and edge computing. CU and DU are connected via the F1 interface. One CU can manage one or more DUs.

In short, the DU is responsible for real-time layer 1 (L1, physical layer) and lower layer 2 (L2), including the data link layer and scheduling functions, while the CU is responsible for non-real-time upper L2 and L3 (network layer) functions. there is.

Next, the definition of each term in the Open RAN (O-RAN) system to which the present invention can be applied is briefly described.

Near-RT RIC: O-RAN Near-Real-Time RAN intelligent controller. It is a logical function that enables near real-time control and optimization of RAN elements and resources through granular data collection and operations through the E2 interface. This can include artificial intelligence/machine learning (AI/ML) workflows, including model training, inference, and updates.

Non-RT RIC: O-RAN Non-real-time RAN intelligent controller and is a logical function within SMO that drives content delivered through the A1 interface. The Non-RT RIC framework and functionality consists of a Non-RT RIC application (rApp) defined below.

Non-RT RIC applications (rApps): Modular applications that provide value-added services related to RAN operations, such as driving the A1 interface, by leveraging functions exposed through the R1 interface of the Non-RT RIC framework. It recommends values and actions that can be subsequently applied through the O1/O2 interface and generates “enrichment information” about the use of other rApps. The rApp function within the Non-RT RIC provides non-real-time control and control of RAN elements and resources. Enables optimization and policy-based guidance on applications/functions of Near-RT RIC.

Non-RT RIC Framework: An SMO internal function that logically terminates the A1 interface for Near-RT RIC and exposes a set of internal SMO services required for runtime processing to rApps through the R1 interface.

Non-RT RIC framework features within Non-RT RIC provide AI/ML workflows including model training, inference, and updates required for rApps.

NMS: A network management system for O-RU designated to support legacy Open Fronthaul M-Plane deployment.

O-Cloud: O-Cloud supports relevant O-RAN features (Near-RT RIC, O-CU-CP, O-CU-UP and O-DU, etc.) and supports software components (e.g. operating system, virtual machine monitor) It is a cloud computing platform consisting of a collection of physical infrastructure nodes that meet O-RAN requirements for hosting functions (e.g., container runtime, etc.).

O-CU-CP: O-RAN Central Unit/Control Plane: A logical node that hosts the RRC and control plane portions of the PDCP protocol.

O-CU-UP: O-RAN Central Unit-User Plane: A logical node that hosts the user plane portion of the PDCP protocol and SDAP protocol.

O-DU: O-RAN Distributed Unit: A logical node that hosts the RLC/MAC/High-PHY layer based on lower layer function division.

O-eNB: An eNB or ng-eNB that supports the E2 interface.

O-RU: O-RAN Radio Unit: A logical node that hosts the Low-PHY layer and RF processing based on lower layer function division. This is similar to 3GPP's "TRP" or "RRH", but is more specific in that it includes a Low-PHY layer (FFT/iFFT, PRACH extraction).

Figure 2 is a diagram showing the logical architecture in an Open RAN (O-RAN) system.

As described with reference to FIG. 2, within the logical architecture of O-RAN, the radio side includes Near-RT RIC, O-CU-CP, O-CU-UP, O-DU, and O-RU functions. The E2 interface connects the O-eNB to the Near-RT RIC. Although not shown in Figure 2, O-eNB supports O-DU and O-RU functions through the Open Fronthaul interface.

The management side includes the SMO framework with Non-RT-RIC functionality. On the other hand, O-Cloud is a cloud computing platform consisting of a collection of physical infrastructure nodes that meet O-RAN. Associated O-RAN features (such as Near-RT RIC, O-CU-CP, O-CU-UP and O-DU), supporting software components (such as operating system, virtual machine monitor, Container Runtime, etc.) and appropriate management. and orchestration functions. Virtualization of O-RU will be studied further in the future. As shown in Figure 2, O-RU terminates the Open Fronthaul M-Plane interface for O-DU and SMO.

Figure 3 is a diagram to explain latency for each application service.

Referring to Figure 3, various application services are provided in 5G systems, etc. Even in the 5G system, application services where latency or delay is considered very important have expanded. In the area indicated by the dotted line in Figure 3, application services such as disaster alert, real time gaming, autonomous driving, augmented reality, virtual reality, and tactile Internet are particularly prone to latency. ) is very important, so the Application Data Unit (ADU) must be delivered within the desired time.

Figure 4 is a diagram illustrating the protocol stack-user plane of 5G, 6G, etc.

Referring to Figure 4, in order to achieve the goal of URLLC, ultra-low latency is required in lower layers. In other words, ultra-low latency is required in lower layers (layer 2/3) such as IP/SDAP/PDCP/RLC/MAC layers to provide URLLC service (i.e., at packet-level low delay). Likewise, services where latency is important in 5G systems, etc. require that ADUs be delivered within the desired time, but this has not yet been solved at the application level. In the present invention, the API and socket concepts used will be briefly described.

API stands for Application Programming Interface, a set of definitions and protocols for building and integrating application software. APIs allow you to communicate with products or services whose implementation you do not know, and they simplify application development, saving you time. and costs can be saved. When designing new tools and products or managing existing ones, APIs provide greater flexibility and simplify design, management, and use. APIs work by having one party send a remote request structured in a certain way, and the other party's software responds. APIs simplify how developers integrate new application components into existing architectures. The API proposed in the present invention is a network transport API capable of guaranteeing 6G end-to-end application level delay.

Socket (can be called variously, such as socket module, socket structure, etc.) is a transport layer of OSI 7 layer that is allocated resources provided by various OSs and provides an interface through which applications can use TCP/IP network functions. It can be defined as a software module (SW module) implemented on top of the (Transport layer).

Figure 5 is a diagram illustrating the 6G end-to-end network structure.

Intelligent real-time resource allocation technology is required to guarantee delay performance at the 6G end-to-end application level. In order to realize such intelligent real-time resource allocation, it is necessary to comprehensively utilize information from various sections (e.g., host, network) and layers (e.g., application layer, transport layer). However, existing network application services are based on traditional socket programming (or may be called variously such as socket module, socket structure, etc.). The existing socket structure has a limited role due to the division of roles between network layers, so it serves as a structure that connects application services and the network, but also serves to disconnect them. For example, network congestion information is reflected in congestion control of the transport layer, but although it can be used to adjust the data unit size of the application layer, transmission is limited. In order to solve this problem, it is necessary to provide a host-network mutual information interconnection architecture and an information interconnection architecture between network layers.

There was a problem of disconnection of essential information due to the division of roles between existing network layers. To solve this problem, 6G network status (NS) information was mutually utilized to provide 6G end-to-end information based on application control and application data information. Control the network.

In addition, as shown in the lower part of FIG. 5, the size of the application data unit (ADU) that the electronic device at the transmitting end wants to transmit can be changed in real time, and network conditions such as network congestion can also be changed. Therefore, from the time the network transmission API (hereinafter simply referred to as API) function is called in the application layer of the electronic device at the transmitting end, the on-time transmission target delay value (i.e., It is important to complete the transmission with the target application time delay (Target_AL) value. As an allowable range for ultra-precise on-time transmission, there may be a delay tolerance for the target application time delay (Target_AL) value. Even if transmission is not on time according to the target application time delay (Target_AL) value, there may be a type of application service (e.g., an application service that is less sensitive to time delay) that is okay for application data to arrive within the delay tolerance value.

FIG. 6 is a diagram showing the configuration of an electronic device 600 at the end that can be applied to embodiments of the present invention.

Referring to FIG. 6 , the electronic device 600 (eg, a mobile terminal) may include a processor 610, a socket module 620, and a radio frequency (RF) unit 630. Here, the RF unit 116 may be a radio unit (RU) in communication systems such as 5G NR and 6G. The processor 610 may be configured to implement the procedures and/or methods proposed in the present invention, and may control information processed by the socket module 620 to be transmitted to the network through the RF unit 630. The memory (not shown) may store the socket module 620 and is connected to the processor 610 to exchange signals with the processor 610 and store various information related to operation. The RF unit 630 is electrically connected to the processor 610 and transmits and/or receives wireless signals.

FIG. 7 is a diagram illustrating the structure of the socket module 620 of the electronic device 600 proposed by the present invention for on-time transmission of 6G end-to-end application services and the operation of the electronic device 600.

Figure 7 relates to a method for the electronic device 600 to transmit 6G end-to-end application services on time. In order to transmit 6G end-to-end application services with high precision and on time, the application layer of the electronic device 600 calls an API function and provides raw data to the encoder of the lower layer of the application layer. Here, raw data can be considered as raw data for application services and is distinguished from ADU as raw data that must be transmitted to the application layer at the destination end. The API proposed in the present invention can be defined as an application-level delay guaranteed transmission API.

The API function called by the application layer may be 6G_Send(Raw_data) as an example. The 6G_Send function proposed in the present invention is a function for application-level latency guarantee. The argument in the 6G_Send function may contain only raw data (6G_Send (Raw_Data)).

That is, as an example, 6G_Send(Raw_data, Service_id=default_value, Target_AL=default value, Tolerance=default value); If you define it as and call ALG_Second (Raw_data), the encoder, socket module, and transport layer recognize Service_ID, Target_AL, and Tolerance as default values defined in advance. Here, Service_ID may be an identifier (eg, IP address, etc.) for an edge server capable of the desired operation. Target_AL refers to the target time required to complete the transmission of raw data from the application layer of the transmitter end to the application layer of the destination end from the time of the function call (or the target application delay time for which transmission completion is desired to be guaranteed), and Tolerance refers to the time the raw data takes to complete transmission. This refers to the allowable error range that does not harm application performance even if it arrives at the application layer of the destination endpoint before or after the target application delay time (Target_AL). Tolerance may vary depending on the type of application service. As an example, in the case of application services that are extremely time-sensitive, such as surgery videos in the case of remote surgery, the Tolerance value may be very small. The function of the 6G_Send(Raw_data) function guarantees the completion of transmission of raw data from the application layer at the sender end to the application layer at the destination (receiver) end within the range of the default target application delay time (Target_AL) value ± the default Tolerance value from the time of the function call. will be.

Referring to FIG. 7, the encoder receives information about network status (NS) from a socket (or socket module). The socket can receive information about the NS through the transport layer. Information about this NS is received by the electronic device 600 from the network (via the E2E slice/resource Orchestrator from the base station) through the RF unit 630, and the information about this NS is transmitted through the PHY/MAC/network layer. It is passed down to the hierarchy. As described above, the transport layer provides information about the NS through a socket.

The information about the NS may include at least one of information about network congestion, information about wireless channel status of the network, and information about resource allocation in the network.

First, information about network congestion may be all categories of network congestion information used in the transport layer, for example, information about packet loss, information for TCP (Transmission Control Protocol) control, or It can be expressed as information about RTT (Round-Trip Time) related to TCP control, or ECN (Explicit Congestion Notification) mark.

Among the information about NS, information about the wireless channel status of the network may be information about the required compression rate of the raw data for end-to-end on-time transmission of the application service.

Among the information about the NS, information about the resource allocation of the network (Allocated Slice/Resource information of Core/RAN) includes information about the compression rate that enables 6G end-to-end on-time transmission using the maximum available resources (information about the paid compression rate). It can be included. Among NS information, the electronic device 600 can receive information about network wireless channel status and information about network resource allocation from the network in the form shown in Table 1 below.

The network determines and informs the electronic device 600 of the required compression rate corresponding to '11' rather than the required compression rate corresponding to '00' in Table 1 as the wireless channel condition is good. Conversely, as the wireless channel condition is poor, the network determines the required compression rate corresponding to '11' in Table 1. The electronic device 600 can be informed of the required compression ratio corresponding to '00' rather than '11'.

1) field 1) Required compression ratio 2) field 2)Paid compression ratio '00' 0.5 '00' One '01' 0.25 '01' 0.5 '10' 0.125 '10' 0.25 '11' 0.0625 '11' 0.125

Regarding Table 1 as an example, the source of information for Table 1 is the base station (e.g., layers 1 to 3 in the base station), the information processor is the E2E slice/resource Orchestrator, and the information format is n bits. In Table 1, 1) field and 1) required compression rate are for the required compression rate for 6G end-to-end on-time transmission, and 2) field and 2) paid compression rate refer to high-quality ADU using the maximum available resources. This is information about the compression rate that can be transmitted on-time between end-to-end. In Table 1, 4 bits (2 bits + 2 bits structure) are shown as an example, but only information on the required compression rate (e.g., 2 bits) and/or information on the paid compression rate (e.g., 2 bits) can also be delivered as separate signaling.

As an example, the compression rate capable of on-time transmission in the network can be informed to the application layer at the end as '1101' in 4 bits as shown below. This must be compressed to 0.0625 (1/16) for on-time transmission, but is available for a fee. This means that high-quality data compressed to 0.5 (1/2) can be sent using the maximum possible resources.

In the electronic device 600 at the end, an encoder in a lower layer of the application layer encodes raw data based on the NS information and adjusts (or determines) the ADU size to generate an ADU. At this time, the encoder may give priority to information about network congestion among the NS information, or may determine the size of the ADU, encoding rate, etc. by considering only information about network congestion among information about the NS. Additionally, the encoder generates an ADU by compressing raw data based on the required compression ratio included in the information about NS. At this time, the encoder does not always compress the raw data, and depending on the type (type) of the application service, the raw data may be encoded without compression to generate an ADU. As described above, the encoder encodes raw data based on information about the NS and provides the encoded ADU to the socket. Afterwards, the socket transfers (transmits) the ADU to the transport layer, and the ADU can be transmitted to the network through the RF unit 630 through the network/MAC/PHY layer in the transport layer.

Previously, it was explained that the API function called from the application layer may be 6G_Send (Raw data) as an example, but at least one of Service_ID, target application delay time, and tolerance in addition to raw data as a transfer argument to the API function is required. More may be included. For example, if Service_ID, target application delay time, and tolerance are all included, the API function could be 6G_Send(Raw_data, Service_id, Target_AL, Tolerance), or 6G_Send(Raw_data, Service_id, Target_AL), or It can be diverse, such as 6G_Send(Raw_data, Target_AL, Tolerance), etc. As an example, when the application layer calls the API function 6G_Send (Raw_data, Service_id, Target_AL, Tolerance), the encoder receives information about Service_id, Target_AL, and Tolerance in addition to raw data from the application layer. Then, the encoder generates an ADU by encoding the raw data based on the raw data, Service_id, Target_AL, Tolerance, and information about the received NS. Then, the encoder delivers the encoded ADU and information about the received Service_id, Target_AL, and Tolerance to the socket. The socket transmits information about the encoded ADU, Service_id, Target_AL, and Tolerance received from the encoder to the transport layer. Information about the encoded ADU, Service_id, Target_AL, and Tolerance may be transmitted to the network through the RF unit 630 through the network/MAC/PHY layer. The function of the 6G_Send(Raw_data, Service_id, Target_AL, Tolerance) function is to send raw data from the application layer at the sender end through the edge server corresponding to the service_ID within the range of the application delay time (Target_AL) value ± default Tolerance value from the time of the function call. This is to ensure transmission completion at the application layer of the destination (receiver) end. Meanwhile, the function of the 6G_Send(Raw_data, Service_id, Target_AL) function sends raw data from the application layer at the sender end to the destination (receiver) via the edge server corresponding to the service_ID within the range of the application delay time (Target_AL) value from the time of the function call. This is to ensure transmission completion at the end application layer.

As shown in Figure 6, in the present invention, a new structure of the socket module 620 (New socket) is proposed to transmit raw data of the application layer on time from the time of calling the API function to the application layer of the destination end, and the socket module (620) is designed as a structure to resolve the information disconnection between the application layer and the lower layer of the existing socket, and serves to transmit information from the transmission layer and the lower layer of the transmission layer to the encoder of the lower layer of the application layer. The encoder is responsible for delivering the encoded ADU to the lower layer. As described above, the encoder adjusts or determines the ADU size (or encoding bitrate) to enable ultra-precision transmission based on information about the NS (network congestion, resource allocation information, wireless channel status information).

Figure 8 is a diagram illustrating the overall network architecture required for on-time transmission of 6G end-to-end application services according to the present invention.

Referring to Figure 8, the overall network architecture includes an electronic device 600 at the sender end, an End-to-End Slice/Resource Orchestrator 700, and a Core Slice/Resource Controller. A Resource Controller (710), a RAN Slice/Resource Controller (RAN Slice/Resource Controller) (720), and an electronic device (800) at the destination endpoint may be included. The RAN Slice/Resource Controller 720 shown in FIG. 8 corresponds to the RAN intelligent controller (RIC) in the O-RAN standard and may be included in the base station in 3GPP 5G NR, 6G, etc.

In the electronic device 600 at the transmitter end, the application layer calls the network transmission API function to guarantee the application-level delay proposed in the present invention and uses the information of the lower layer of the application layer to determine the ADU size of the encoder and send the ADU. create The electronic device 600 may transmit ADU, which is application layer information, to the network. At this time, if Service_ID, Target_AL, and Tolerance are included as transfer factors in the API call function, the electronic device 600 sends the application layer information (ADU, Service_ID, Target_AL, Tolerance) to the network resource control system (700, 710, 720). The RAN Slice/Resource Controller 720 performs intelligent radio resource allocation based on application layer information (ADU, Service_ID, Target_AL, Tolerance) received from the electronic device 600 at the transmitter end. do. The details of the intelligent radio resource allocation are described in detail in Korean Patent No. 10-2022-0125827 (Radio resource allocation method and device for ensuring performance of end-to-end application-level delay).

As shown in the socket module 620 of FIG. 7, it is designed as an inter-layer information interconnection structure that enables information exchange from the application layer of the electronic device 600 at the transmitting end to the transmission layer, thereby enabling the 6G end-to-end application service. Ultra-precise and on-time transmission becomes possible.

6G end-to-end application to the application layer of the electronic device 800 at the receiving end by adaptively allocating radio resources according to intelligent or real-time channel changes in the RAN Slice/Resource Controller 720 of the base station. On-time delivery of services becomes possible.

Figure 9 is a diagram illustrating signaling information required in the network for on-time transmission of the 6G end-to-end application service according to the present invention.

Referring to FIG. 9, the transport layer of the electronic device 600 (e.g., UE) at the sender's end operates to embed the application information received from the socket module 620 in the transport layer header through packet embedding and transmit it to the network. . The electronic device 600 at the sender end sends the ADU, service_id, target application time delay (Target_AL) value, and tolerance value to the end-to-end slice orchestrator 700, core slice. /Transmitted to the Core Slice/Resource Controller (710) and the RAN Slice/Resource Controller (720), respectively (S910, S920, S930).

The End-to-End Slice Orchestrator (700), Core Slice/Resource Controller (710), and RAN Slice/Resource Controller (720) are Decode the application information (ADU, Service_id, Target_AL, Tolerance) embedded in each transport layer packet header. The Core Slice/Resource Controller 710 utilizes the application information to perform core slice and resource allocation that enables ultra-precise and on-time transmission. The RAN Slice/Resource Controller (RAN Slice/Resource Controller) 720 utilizes the corresponding application information to perform RAN slice and resource allocation that enables ultra-precise and on-time transmission.

Afterwards, the RAN Slice/Resource Controller (720) transmits information about RAN slices capable of ultra-precise and on-time transmission and resource allocation to the End-to-End Slice Orchestrator (700). Deliver (S940). At this time, the RAN Slice/Resource Controller (RAN Slice/Resource Controller) 720 provides information on the wireless channel status (e.g., information on the required compression rate) in addition to information on the RAN slice and resource allocation through a slice orchestrator ( It can be delivered to the End-to-End Slice Orchestrator (700) (S940).

The Core Slice/Resource Controller (710) transmits information about core slices and resource allocation capable of ultra-precise and on-time transmission to the End-to-End Slice Orchestrator (700). (S950).

The End-to-End Slice Orchestrator (700) provides feedback information about the information received in steps S940 and S950 to the Core Slice/Resource Controller (710) and the RAN Slice/Resource Controller (710). It can be transmitted to the resource controller (RAN Slice/Resource Controller) 720, respectively (S960, S970).

The end-to-end slice orchestrator (700) receives resource allocation and wireless channel status information in steps S940 and S950, and generates information about the NS as is or by processing the received information. The packet can be embedded and transmitted so that it can be delivered to the encoder below the application layer of the electronic device 600 at the end.

According to the network end-to-end transmission method of application services according to the present invention described above, 6G end-to-end application level delay performance is guaranteed and ultra-sensitive application services are delivered on time with ultra-precision on-time from the application layer at the transmitter end to the application layer at the destination end. Transmission becomes possible.

The embodiments described above are those in which the components and features of the present invention are combined in a predetermined form. Each component or feature should be considered optional unless explicitly stated otherwise. Each component or feature may be implemented in a form that is not combined with other components or features. Additionally, it is also possible to configure an embodiment of the present invention by combining some components and/or features. The order of operations described in embodiments of the present invention may be changed. Some features or features of one embodiment may be included in other embodiments or may be replaced with corresponding features or features of other embodiments. It is obvious that claims that do not have an explicit reference relationship in the patent claims can be combined to form an embodiment or included as a new claim through amendment after filing.

In the present invention, the socket module 620 may be implemented by hardware, firmware, software, or a combination thereof. It is obvious to those skilled in the art that the present invention can be embodied in other specific forms without departing from the essential features of the present invention. Accordingly, the above detailed description should not be construed as restrictive in all respects and should be considered illustrative. The scope of the present invention should be determined by reasonable interpretation of the appended claims, and all changes within the equivalent scope of the present invention are included in the scope of the present invention.

Claims (15)

In a method for an electronic device to transmit an application service between end-to-end networks,
Calling an API function from the application layer to provide raw data to the encoder of the lower layer;
The encoder receiving information about network status (NS) from a socket;
The encoder encoding the raw data based on information about the NS and providing an encoded application data unit (ADU) to the socket;
The socket transmits the ADU to a transport layer; and
A network end-to-end transmission method of an application service, comprising transmitting the ADU to a network through the transport layer. According to clause 1,
The information about the NS includes at least one of information about network congestion, information about wireless channel status of the network, and information about resource allocation in the network. According to clause 1,
Among the information about the NS, information about the wireless channel status of the network and resource allocation information in the network are received from the network. According to clause 2,
The information on the wireless channel status of the network includes information on the required compression rate of the raw data for end-to-end on-time transmission of the application service. According to clause 2,
Information on resource allocation in the network includes information on a compression rate that enables on-time end-to-end transmission using the maximum available resources. According to clause 1,
A network end-to-end transmission method of an application service in which the encoder determines the size of the ADU based on information about the NS. According to clause 1,
The API function is a predefined Application-level Latency Guarantee (ALG) function and includes the raw data transfer argument. A network end-to-end transmission method of an application service. According to clause 7,
When the ALG function includes only the raw data transfer factor, the encoder determines the target application latency (Application latency, A network end-to-end transmission method of an application service that recognizes and processes the AL) value and the allowable tolerance value as a predefined default value even if it arrives before or after the target AL. According to clause 1,
The API function is a predefined Application-level Latency Guarantee (ALG) function, and in addition to the raw data transfer argument, it includes an edge server identifier transfer argument, a target application latency transfer argument, and the target application delay time. A network end-to-end transmission method of an application service that further includes at least one of the tolerance transmission factors that are allowed even if they arrive before or after. According to clause 9,
In the step of providing raw data to the encoder, at least one of the edge server identifier, the target application delay time, and the tolerance information is further provided to the encoder. According to clause 10,
The encoder encodes the ADU based on at least one of the edge server identifier, the target application delay time, and the tolerance information. In an electronic device for transmitting application services between end-to-end networks,
The application layer calls the API function to provide raw data to the encoder in the lower layer,
The socket provides information about network status (NS) to the encoder,
The encoder encodes the raw data based on information about the NS and provides an encoded application data unit (ADU) to the socket,
a socket module configured to allow the socket to pass the ADU to a transport layer; and
An electronic device comprising a processor that controls transmission of the ADU to a network. According to clause 12,
An electronic device in which the encoder in the socket module determines the size of the ADU based on information about the NS. According to clause 12,
If the API function is a predefined Application-level Latency Guarantee (ALG) function and includes only the raw data argument,
In the socket module, the encoder transmits the raw data to the application layer of the destination end from the time of calling the ALG function. Even if it arrives before or after the target application latency (AL) value and the target AL. An electronic device that recognizes and processes allowable tolerance values as predefined default values. According to clause 12,
The API function is a predefined Application-level Latency Guarantee (ALG) function, and in addition to the raw data transfer argument, it includes an edge server identifier transfer argument, a target application latency transfer argument, and the target application delay time. Even if it arrives before or after, it further includes at least one of the allowable tolerance transfer factors,
The encoder in the socket module further considers at least one of the edge server identifier, the target application delay time, and the tolerance information to encode the raw data to generate an ADU.

Images