METHOD AND APPARATUS FOR SUPPORTING QoS IN WIRELESS COMMUNICATION SYSTEM

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. A method performed by a network open function (NEF) entity in a wireless communication system according to the present disclosure may comprise the steps of receiving, from an application function (AF) entity, a first message requesting negotiation of a planned data transfer (PDTQ) policy with QoS, transmitting, to a policy control function (PCF) entity, a second message requesting a decision of the PDTQ policy based on the first message, receiving, from the PCF entity, a third message including information related to the at least one PDTQ policy determined by the PCF entity, and transmitting the information related to the determined at least one PDTQ policy to the AF entity.

Description

Technical Field

[0001] The present disclosure relates to a method and apparatus for supporting QoS of a federated learning service in a wireless communication system. Background Art

[0002] Fifth-generation mobile communication technology defines wide frequency bands, enabling high transmission rates and new services. 5G mobile communication technology can be applied not only to frequency bands "below 6 GHz," such as 3.5 GHz, but also to frequency bands "above 6 GHz," known as mmWave, including 28 GHz and 39 GHz. Furthermore, to achieve transmission rates fifty times faster than 5G mobile communication technology and ultra-low latency one-tenth that of 5G mobile communication technology, 6G mobile communication technology (referred to as a "beyond 5G system") is being considered for implementation in the terahertz frequency band (e.g., the 95 GHz to 3 THz band).

[0003] In the early stages of 5G mobile communication technology, in order to support services associated with enhanced Mobile Broadband (eMBB), Ultra Reliable & Low Latency Communications (URLLC), and massive Machine-Type Communications (mMTC) and meet the performance requirements associated therewith, standardization is underway on the following items: beamforming and massive MIMO for mitigating radio wave path loss and increasing radio wave transmission range in millimeter waves, parameter sets (numerology, for example, operating multiple subcarrier spacings) for efficient utilization of millimeter wave resources and dynamic operation of time slot formats, initial access technology supporting multi-beam transmission and broadband, definition and operation of BWP (bandwidth part), new channel coding methods such as LDPC (low-density parity check) codes for large-capacity data transmission and polar codes for highly reliable transmission of control information, L2 preprocessing, and network slicing for providing dedicated networks tailored to specific services.

[0004] Currently, in view of the services to be supported by 5G mobile communication technology, discussions are underway on improvements and performance enhancements to initial 5G mobile communication technology, and there is already physical layer standardization on technologies such as Vehicle-to-Everything (V2X) for assisting driving determination of autonomous vehicles based on information about the location and status of vehicles transmitted by vehicles and for enhancing user convenience, New Radio Unlicensed (NR-U) for system operation in unlicensed frequency bands that complies with various regulatory requirements, NR UE power saving, Non-Terrestrial Network (NTN) as UE-satellite direct communication for securing coverage in areas where communication with terrestrial networks is unavailable, and positioning.

[0005] Furthermore, in the area of radio interface architecture / protocols, standardization is underway on technologies such as the Industrial Internet of Things (IIoT) for supporting new services through interworking and integration with other industries, Integrated Access and Backhaul (IAB) for providing nodes for network service area expansion by integrating wireless backhaul links and access links, mobility enhancements including conditional handover and Dual Active Protocol Stack (DAPS) handover, and two-step random access (NR two-step RACH) for simplifying the random access procedure. In the area of system architecture / services, standardization is also underway on a 5G baseline architecture (e.g., a service-based architecture or service-based interface) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) for receiving services based on UE location.

[0006] If such a 5G mobile communication system is commercialized, the already exponentially growing number of connected devices will be connected to the communication network, and it is therefore expected that enhanced functionality and performance of the 5G mobile communication system and the integrated operation of connected devices will be necessary. To this end, new research is being planned related to: xtended reality (XR) for efficient support of augmented reality (AR), virtual reality (VR), mixed reality (MR), etc.; 5G performance improvement and complexity reduction through the use of artificial intelligence (AI) and machine learning (ML); support for AI services; support for metaverse services; and drone communications.

[0007] Furthermore, such advancements in 5G mobile communication systems will serve not only as a foundation for the development of new waveforms, Full Dimensional MIMO (FD-MIMO), multi-antenna transmission technologies (such as array antennas and massive antennas) for ensuring coverage in the terahertz band for 6G mobile communication technology, metamaterial-based lenses and antennas for improving coverage of terahertz band signals, high-dimensional spatial multiplexing technologies using orbital angular momentum (OAM), and reconfigurable intelligent surfaces (RIS), but will also serve as a foundation for the development of full-duplex technologies for improving the frequency efficiency and system networks of 6G mobile communication technology, AI-based communication technologies for achieving system optimization by leveraging satellites and AI (artificial intelligence) from the design stage and internalizing end-to-end AI support functions, and next-generation distributed computing technologies for implementing services with a complexity level that exceeds the operational capabilities of UEs by utilizing ultra-high-performance communication and computing resources. Summary of the Invention

[0008] Technical issues

[0009] The present disclosure provides a method and device for supporting QoS in a wireless communication system. Specifically, a method and device for allocating network resources in a wireless communication system taking into account traffic of a federated learning service are proposed.

[0010] Solution

[0011] According to an embodiment proposed in the present disclosure, a method performed by a network exposure function (NEF) entity in a wireless communication system may include: receiving a first message requesting negotiation of a planned data transfer with QoS (PDTQ) policy from an application function (AF) entity; sending a second message requesting determination of the PDTQ policy to a policy control function (PCF) entity based on the first message; receiving a third message including information related to at least one PDTQ policy determined by the PCF entity from the PCF entity; and sending information related to at least one determined PDTQ policy to the AF entity.

[0012] A method performed by a policy control function (PCF) entity in a wireless communication system may include: receiving a first message from a network exposure function (NEF) entity requesting the determination of a planned data transfer (PDTQ) policy with QoS based on a request of an application function (AF) entity; sending a second message to a unified data repository (UDR) entity requesting a pre-stored PDTQ policy and information for determining the PDTQ policy of the AF entity; receiving a third message from the UDR entity including the pre-stored PDTQ policy and information for determining the PDTQ policy of the AF entity; determining at least one PDTQ policy based on the third message; and sending a fourth message to the NEF entity including at least one determined PDTQ policy and information related to the at least one determined PDTQ policy, wherein the PDTQ policy indication can be provided to a third party.

[0013] A network exposure function (NEF) entity in a wireless communication system may include: at least one transceiver; and a controller coupled to the at least one transceiver. The controller may be configured to: receive a first message from an application function (AF) entity requesting negotiation of a planned data transfer with QoS (PDTQ) policy; send a second message to a policy control function (PCF) entity requesting determination of a PDTQ policy based on the first message; receive a third message from the PCF entity including information related to at least one PDTQ policy determined by the PCF entity; and send the information related to the at least one determined PDTQ policy to the AF entity.

[0014] A policy control function (PCF) entity in a wireless communication system may include: at least one transceiver; and a controller coupled to the at least one transceiver. The controller may be configured to: receive a first message from a network exposure function (NEF) entity requesting determination of a planned data delivery with QoS (PDTQ) policy based on a request from an application function (AF) entity; send a second message to a unified data repository (UDR) entity requesting pre-stored PDTQ policies and information for determining the PDTQ policy of the AF entity; receive a third message from the (UDR) entity including the pre-stored PDTQ policies and information for determining the PDTQ policy of the AF entity; determine at least one PDTQ policy based on the third message; and send a fourth message to the NEF entity including the at least one determined PDTQ policy and information related to the at least one determined PDTQ policy. The PDTQ policy indicates at least one QoS policy that may be provided to a third party.

[0015] Beneficial effects

[0016] According to the embodiments proposed in the present disclosure, in the case where the request from an external third party in the 5G system is a request for federated learning traffic or a request for traffic for a service that does not need to be provided in real time, a new QoS flow is always allocated, thereby reducing the adverse effects of FL learning traffic on traffic of application services that need to be sent in real time (i.e., reduced throughput, increased latency, etc.).

[0017] The beneficial effects obtainable by the present disclosure may not be limited to the above-mentioned effects, and other effects not mentioned may be clearly understood by those skilled in the art to which the present disclosure belongs from the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 The 5G system architecture according to various embodiments of the present disclosure is shown.

[0019] Figure 2 An example is shown of processing QoS requests for multiple UEs based on a new 5QI value in the process of the AF sending a QoS request to the 5G core network according to various embodiments of the present disclosure.

[0020] Figure 3 The data transmission policy negotiation process according to various embodiments of the present disclosure is shown.

[0021] Figure 4 A method for generating PCC rules based on a data delivery policy according to various embodiments of the present disclosure is shown.

[0022] Figure 5 The structure of a base station according to various embodiments of the present disclosure is shown.

[0023] Figure 6The structure of a UE according to various embodiments of the present disclosure is shown. DETAILED DESCRIPTION

[0024] When a mobile communication UE application service provider (i.e., application service provider (ASP)) operates services based on a machine learning model, the machine learning model can be trained based on the collected data to provide better services.

[0025] To train machine learning models, the ASP can leverage federated learning (FL), involving multiple UEs. Specifically, applications operating in each UE train local models using collected local data and only send the resulting local updates (i.e., gradients) to the server. The server aggregates the local updates from each application to train a global model and redistributes it to the applications. Furthermore, network resources must be allocated separately for FL traffic to ensure that traffic serving applications requiring real-time delivery is not adversely impacted by FL traffic (i.e., reduced throughput, increased latency, etc.). Furthermore, each application participating in FL can have a different learning speed (i.e., the speed at which learning results are sent to the server) depending on the network conditions of the UE driving the application, and the overall learning speed of the FL is determined by the member (i.e., application or UE) with the slowest learning speed. Therefore, if the network resources allocated to UEs participating in FL vary significantly, network resources allocated to UEs with more resources may go unused.

[0026] This disclosure proposes a method for allocating network resources based on federated learning traffic. Specifically, in a mobile communication system, an external ASP requests QoS configuration for multiple UEs. If the request is for federated learning traffic (or traffic that does not require real-time provisioning), the mobile communication system always allocates a new QoS flow when allocating resources for the request, thereby minimizing the impact on existing traffic (i.e., real-time traffic).

[0027] Figure 1 The 5G system architecture according to various embodiments of the present disclosure is shown.

[0028] refer to Figure 1The 5G mobile communication network may include a 5G user equipment (UE) (terminal) 100, a 5G radio access network (RAN, base station, 5G node B (gNB), evolved node B (eNB), etc.) 110, and a 5G core network. The 5G core network may include network functions (NFs), such as an access and mobility management function (AMF) 120 that provides UE mobility management functions, a session management function (SMF) 135 that provides session management functions, a user plane function (UPF) 130 that performs a data transfer role, a policy control function (PCF) 140 that provides a policy control function, a unified data management (UDM) 145 that provides functions for managing data such as subscriber data and policy control data, or a unified data repository (UDR) that stores data of various NFs such as the UDM.

[0029] In the 3GPP system, the conceptual link connecting NFs in the 5G system is defined as a reference point. Figure 1 Examples of reference points included in the 5G system architecture are described in, but are not limited to, these.

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

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

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

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

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

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

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

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

[0038] - N9: Reference point between the two core UPFs

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

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

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

[0042] - N13: Reference point between UDM and the authentication server function (AUSF)

[0043] - N14: Reference point between two AMFs

[0044] - N15: Reference point between PCF and AMF in non-roaming scenarios, and between PCF and AMF in visited networks in roaming scenarios

[0045] In the 5G system, network slicing refers to a structure and technology that enables multiple independent logical networks to be virtualized in a single physical network. To meet the specific needs of services / applications, network operators provide services by configuring virtual end-to-end networks called network slices. In this case, network slices are distinguished by an identifier called single-network slice selection assistance information (S-NSSAI). The network sends a set of allowed slices (e.g., allowed NSSAI) to the UE during the UE registration process, and the UE sends and receives application data through a protocol data unit (PDU) session generated by an S-NSSAI (i.e., network slice) in the set of allowed slices.

[0046] The mobile communication system is provided with the identity information and quality of service (QoS) requirements of UEs that can participate in federated learning from an external third-party server (application function AF), selects UEs for which network resources are allowable based on these requirements, allocates network resources (i.e., QoS flows), and sends the results to the AF. Among the terms used in the present disclosure description, the term "aggregate QoS" may be used and interpreted as synonymous with "same QoS", "same QoS", and "group QoS". For example, "aggregate QoS request indicator" may be used and interpreted as synonymous with "same QoS request indicator", "aggregate QoS information" may be used and interpreted as synonymous with "same QoS information", and "aggregate QoS notification indicator" may be used and interpreted as synonymous with "same QoS notification indicator".

[0047] Figure 2An example is shown of processing QoS requests for multiple UEs based on a new 5QI value in the process of the AF sending a QoS request to the 5G core network according to various embodiments of the present disclosure.

[0048] refer to Figure 2 In step 205, the AF may send a message to the NEF to request creation / update / deletion of network resources (eg, QoS) for a specific service.

[0049] The message for requesting to create / update / delete a network resource for a specific service may include the following information. However, the present disclosure is not limited thereto.

[0050] - Flow description or external application identifier: Flow information about each service (e.g., server IP address, server port number, protocol information, etc.) and the external application identifier for that service

[0051] - UE address list: a list configured by UE address (e.g. IP address, MAC address, GPSI, external identity)

[0052] - Group ID: Group ID (external group ID or internal group ID) instead of UE address list. In case of update request to update the mapping between UE address list and group ID, both information can be included at the same time.

[0053] - AF Identifier: AF Identifier

[0054] - QoS parameters: Indicates various QoS parameters, including requested 5GS latency, requested priority, requested guaranteed bit rate, and requested maximum bit rate. Additionally, this may include flow direction, burst size, burst arrival time at the UE (uplink) or UPF (downlink), periodicity, time domain, and time to live.

[0055] - QoS Reference: In case that various QoS parameters are not included in the QoS requirements, a QoS reference indicating predefined various QoS parameters may be included.

[0056] - Separate Binding Indication: An indicator for requesting generation of a new QoS flow instead of an existing QoS flow, which is generated with respect to the QoS parameters and flow description included in the request message.

[0057] In step 210, after receiving the request message from the AF in step 205, the NEF may perform authorization on the request message of the NEF. In a case where the number of UEs corresponding to the UE address list in the AF request message or the number of UEs included in the replacement requirement is greater than a predefined number, the NEF may omit steps 215 and 220, and may send a message including an indicator indicating that the request is rejected, a reason value indicating that the rejection is due to an excess of the number of UEs, and the number of allowable UEs to the AF in step 225.

[0058] In step 215, the NEF may store some or all of the information received from the AF in step 205 in a unified data repository (UDR). The NEF may perform PCF discovery (discovering PCFs) for the UE address list received from the AF through a binding support function (BSF). The NEF may send the UE address list or the UE identifier or FL group ID corresponding to the UE address list via a PCF discovery request message to the BSF. After receiving this message, the BSF may send information about the PCF and the UE addresses and / or UE identifiers handled by the PCF to the NEF. The BSF may store the FL group ID, PCF ID, and the UE address list for each PCF.

[0059] In the case that multiple PCFs are discovered, the NEF may generate a separate identifier (sub-FL group ID) for the UE address list of each PCF and may store it in the UDR as data associated with the FL group ID.

[0060] In the case that multiple PCFs are discovered, the NEF may send a request message to each PCF, and the message may include only the addresses of UEs handled by the corresponding PCF in the UE address list received from the AF in step 205. The NEF may include a UE ID corresponding to the UE address for each UE in the message sent to the PCF.

[0061] In addition to the above information, the NEF may transmit a plurality of pieces of information included in the message received from the AF in step 205 to the PCF.

[0062] In case the message received from the AF in step 205 has only the UE address list and / or the FL group ID, the NEF may not send a message to the PCF, and may send a response message to the AF in step 225 to inform that the FL group has been generated.

[0063] According to an embodiment of the present disclosure, the message sent by the NEF to the PCF may be an Npcf_PolicyAuthorization_Create request message.

[0064] In step 220, the PCF may send a response message to the NEF.

[0065] In step 225, the PCF may identify PDU sessions for all UEs corresponding to the UE address list included in the message received in step 215 based on the information included in the message received in step 215. In addition, the PCF may generate a PCC rule for each PDU session based on the information included in the message received in step 215. In the case where the message received in step 215 has a separate binding indication, the PCF may generate the PCC rule so as to include "binding to a separate QoS flow" (e.g., an indicator instructing to bind the PCC rule to a separate QoS flow). The PCC rule may also not include "binding to a separate QoS flow". In addition, information about each QoS flow may be stored to indicate whether the QoS flow corresponds to a separate binding.

[0066] In step 230, the PCF may include the following information in a message sent to the SMF. However, the present disclosure is not limited thereto.

[0067] - SM Policy Association ID: Indicates the policy-related identifier regarding the PDU session corresponding to the PCC rule determined in step 5.

[0068] - PCC rules: service data flow (SDF) template (application ID, IP filtering information, etc.), QoS parameters to be applied to SDF flows, ARP

[0069] - Binding to separate QoS flow: Information instructing to bind the PCC rule to a separate QoS flow, and this information may be included in the PCC rule or as a separate parameter.

[0070] In step 235, the SMF may send a response message to the PCF.

[0071] In step 240, the SMF may perform binding on the PCC rule received in step 6 within the PDU session corresponding to the SM policy association ID in the message received from the PCF in step 230. In the case where the message received in step 230 includes "binding to a separate QoS flow", even if a QoS flow with the same parameters as those included in the PCC rule exists in the PDU session, the SMF may generate a new QoS flow instead of using the same QoS flow. Specifically, the SMF may include the QoS profile generated based on the corresponding PCC rule in a message sent to the base station (i.e., the radio access network (RAN)), and may include the generated QoS profile in a message sent to the UE.

[0072] In step 245, the NEF may send a response message to the AF message in response to the message requesting to create / update / delete network resources for a specific service.

[0073] Figure 3 The data transmission policy negotiation process according to various embodiments of the present disclosure is shown.

[0074] When a small application operator wants to send application traffic to one or more UEs, he / she can use the AF to perform the following procedures to negotiate a policy for traffic transmission. As the service operation used in each procedure, the service operation for the background data transmission policy (e.g., Nnef_BDTPNegotiation_Create / Update / Delete, Npcf_BDTPolilcy_Create / Update / Delete) can be used, or the service operation defined for the scheduled data transmission policy including QoS information (e.g., Nnef_PDTQPolicyNegotiation_Create / Update / Delete, Npcf_PDTQPolicyNegotiation_Create / Update / Delete) can be used. In the case where the service operation defined for the scheduled data transmission policy including QoS information is used, the AF can select multiple data transmission policies for each reference ID in step 345, and the multiple data transmission policies for each reference ID can be stored in the UDR in steps 355 and 360.

[0075] In step 305, when the mini-app operator wants to send application traffic to one or more UEs, he / she can use the AF to perform the following process to negotiate a traffic delivery policy. This process can be performed using the Nnef_BDTPNegotiation_Create request for background data transfer or a separate message (e.g., a message for application data transfer). The AF includes the following information in the message sent to the NEF for the data delivery policy negotiation message.

[0076] - ASP Identifier: refers to the identifier of the Application Service Provider (ASP).

[0077] - Number of UEs: refers to the number of UEs to which the traffic of small applications is expected to be sent.

[0078] - Volume per UE: refers to the amount of data to be sent to each UE.

[0079] - Expected time window: includes information about the time window during which the applet's traffic is expected to be sent.

[0080] - External group identifier, internal group identifier, UE ID list: refers to information used to identify the UE to which the data delivery policy is to be applied. An externally used group identifier, an internally used group identifier, or a UE identifier list may be used.

[0081] - Network area information: refers to information about the area where data transmission is expected to occur. Geographic information may be included.

[0082] - Notification Request: Parameter used to request the NEF to send a data transfer warning notification to the AF (e.g., to notify the AF in case of a data transfer performance degradation).

[0083] - MAC address or IP triplet of the application server: This refers to the MAC address (for example, Ethernet MAC address) or IP information (for example, the server's IP address, port number, and protocol information) used to identify the application server.

[0084] - Separate QoS flow indication: During data transfer, this parameter is used to request the use of a separate QoS flow for data transfer. For example, in the case of federated learning traffic, a separate QoS flow for this traffic can be generated and used (i.e., this QoS flow is not shared with traffic from other applications).

[0085] - QoS related information: refers to the QoS information required for data transmission, etc. Minimum bit rate, bit rate difference between QoS flows, maximum delay, etc. may be included.

[0086] - QoS Reference ID: may include a value or information indicating a standardized 5QI or a predefined 5QI (ie, a 5QI value indicating a specific QoS feature pre-stored in the RAN).

[0087] In the case that the message received in step 305 includes an external group identifier, the NEF may request the UDM to convert it, thereby obtaining an internal group identifier corresponding to the external group identifier.

[0088] In step 310, if the message received in step 305 includes a UE ID list, an external group identifier, or an internal group identifier, the NEF may include the UE ID list, the external group identifier, or the internal group identifier in a PCF discovery request message sent to the BSF. Alternatively, the NEF may obtain the corresponding PCF address through configuration information.

[0089] In step 315, the BSF may include the address of the PCF corresponding to the information included in the message received in step 310 in the message sent to the NEF.

[0090] In case the message received in step 310 includes a list of UE IDs, the BSF may include the address of the PCF that handles the UEs included in the list.

[0091] In addition, if the message received in step 310 includes an external group identifier, the BSF includes the address of the PCF that processes the external group identifier. If the message received in step 310 includes an internal group identifier (e.g., the internal group identifier obtained in step 310), the address (e.g., fully qualified domain name (FQDN) etc.) of the PCF that processes the internal group identifier may be included.

[0092] In step 320, the NEF may include the following content in a message sent to each PCF regarding part or all of the addresses of the PCFs obtained in step 315. However, the present disclosure is not limited thereto.

[0093] - ASP Identifier: refers to the identifier of the Application Service Provider (ASP).

[0094] - Number of UEs: refers to the number of UEs to which the traffic of small applications is expected to be sent.

[0095] - Volume per UE: refers to the amount of data to be sent to each UE.

[0096] - Expected time window: includes information about the time window during which the applet's traffic is expected to be sent.

[0097] - External group identifier, internal group identifier, UE ID list: refers to information used to identify the UE to which the data delivery policy is to be applied. An externally used group identifier, an internally used group identifier, or a UE identifier list may be used.

[0098] - Network area information: including a list of cell IDs or a list configured by TA ID. In case the message received in step 305 includes geographical information, the NEF converts it into a corresponding list of cell IDs or a list configured by TA ID.

[0099] - Notification Request: Parameter used to request the NEF to send a data transfer warning notification to the AF (e.g., to notify the AF in case of a data transfer performance degradation).

[0100] - MAC address or IP triplet of the application server: This refers to the MAC address (for example, Ethernet MAC address) or IP information (for example, the server's IP address, port number, and protocol information) used to identify the application server.

[0101] - Separate QoS flow indication: During data transfer, this parameter is used to request the use of a separate QoS flow for data transfer. For example, for federated learning traffic, a separate QoS flow for this traffic can be generated and used (i.e., this QoS flow is not shared with traffic from other applications).

[0102] - QoS related information: refers to the QoS information required for data transmission, etc. Minimum bit rate, bit rate difference between QoS flows, maximum delay, etc. may be included.

[0103] - QoS Reference ID: may include a value or information indicating a standardized 5QI or a predefined 5QI (ie, a 5QI value indicating a specific QoS feature pre-stored in the RAN).

[0104] In step 325, the H-PCF may include the following information in the message sent to the UDR. However, the present disclosure is not limited thereto.

[0105] - Strategy Data

[0106] - Background data transfer

[0107] In step 330, in the case that the message received in step 325 includes policy data and background data transfer, the UDR may include the data transfer policy for all ASPs in the response message sent to the H-PCF.

[0108] In step 335, the H-PCF may determine one or more data delivery policies based on the information contained in the message received in step 320 (i.e., the information sent from the AF) and the information received in step 330. Furthermore, the H-PCF determines a policy reference ID indicating the one or more data delivery policies. The data delivery policies and policy reference IDs may relate to background data delivery or application data delivery.

[0109] The data transmission policy may include the following information. However, the present disclosure is not limited thereto.

[0110] - The recommended time window for data transmission and the reference billing rate for this time window,

[0111] - Separate QoS flow indication: During data transmission, this parameter is used to request the use of a separate QoS flow for data transmission. If the message received in step 320 includes this parameter, this parameter may be included.

[0112] - QoS related information: refers to the QoS information required for data transmission, etc.

[0113] - QoS Reference ID: may include a value or information indicating a standardized 5QI or a predefined 5QI (ie, a 5QI value indicating a specific QoS feature pre-stored in the RAN).

[0114] In step 340, the H-PCF may include the policy reference ID determined in step 335 and the corresponding data transmission policy in a response message sent to the NEF. One or more data transmission policies may be included therein.

[0115] In step 345 , the NEF may include the policy reference ID and one or more data delivery policies in the message received in step 340 .

[0116] In the case that the message received by the NEF in step 340 includes the policy reference ID and one data delivery policy, step 350 may be omitted and step 355 may be executed.

[0117] If the AF has received multiple data delivery policies in step 345, the AF may select a data delivery policy and then include the reference ID and the selected data delivery policy in a message sent to the NEF in step 350. The NEF may include the reference ID and the selected data delivery policy included in the message received from the AF in a message sent to the H-PCF. The H-PCF sends a response message to the NEF, and the NEF sends a response message to the AF.

[0118] In step 355, the H-PCF may store the data transmission reference ID and the data transmission policy in its central unit or in the UDR. The H-PCF may include the following content in the message sent to the UDR. However, the present disclosure is not limited thereto.

[0119] - Reference ID: an identifier used to identify the connection with the AF related to the data transfer policy negotiation. This identifier is the same as the reference ID in step 335.

[0120] - Dataset: can be configured to indicate the value of policy data.

[0121] - Data Subset: configured as a value indicating background data delivery data or a value indicating a scheduled data delivery policy with QoS requirements.

[0122] - Data transmission policy: refers to the data transmission policy determined in step 335 , or refers to the data transmission policy selected by the AF in step 350 from the data transmission policies determined in step 335 .

[0123] In step 360, the UDR stores the data delivery policy received in step 355 in an internal repository corresponding to the reference ID, data set, and data subset received in step 355. The UDR may send a response message to the H-PCF.

[0124] In step 365, the H-PCF may update the URSP rules based on the determined data delivery policy. For UEs corresponding to the data delivery policy, the PCF may include the updated URSP rules for each UE in a UE policy container and send it to the serving AMF for the UE. The serving AMF may include the UE policy container in a UE Configuration Update Request message sent to the UE.

[0125] In step 370, the H-PCF may add the reference ID to the PDU session-related policy data stored in the UDR. The H-PCF may include the following information in the message sent to the UDR. However, the present disclosure is not limited thereto.

[0126] - Dataset: A value configured to indicate policy data.

[0127] - Data Subset: A value configured to indicate PDU session policy control data.

[0128] - Key: includes UE identifier information (e.g., SUPI). The H-PCF can identify the relevant UE based on the information included in the data delivery policy, and can include the corresponding UE identifier information when updating the PDU session policy control data for each UE.

[0129] - Subkey: Includes S-NSSAI (i.e., slice identifier information) and DNN (i.e., data network name information). The H-PCF may include the S-NSSAI and DNN corresponding to the Application Server Policy (ASP) ID included in the data delivery policy.

[0130] - Reference ID: refers to an identifier indicating a data delivery policy.

[0131] In step 375 , the UDR may send a response message to the message received in step 370 to the H-PCF.

[0132] Figure 4 A method for generating PCC rules based on a data delivery policy according to various embodiments of the present disclosure is shown.

[0133] refer to Figure 4 In step 405, the PCF may obtain the PDU session policy control data stored in the UDR.

[0134] In the event that the PDU session policy control data changes, the UDR may include the PDU session policy control data in a Nudr_DM_Notify message sent to the PCF handling the corresponding session.

[0135] After receiving the Nudr_DM_Query message from the PCF, the UDR may include PDU session policy control data corresponding to the S-NSSAI, DNN, and SUPI included in the received message in a response message sent to the PCF.

[0136] In step 410, in the case where the AF wants to apply the data transfer policy to the established PDU session, the AF may include the following information in a message sent to the NEF. However, the present disclosure is not limited thereto.

[0137] - Reference ID: Contains the identifier of the data delivery policy to be applied.

[0138] - AF session information: includes information to be used to identify the AF session. ASP ID (or S-NSSAI and DNN)

[0139] - UE Information Group: can include UE ID list or group ID (external group ID or internal group ID).

[0140] In step 415 , the NEF may acquire the S-NSSAI and DNN based on the ASP ID included in step 410 .

[0141] In case the group ID is included in step 410, the NEF may acquire a UE ID list corresponding to the group ID.

[0142] The NEF sends a message to the BSF to request information about the PCF, and the message includes the following information. However, the present disclosure is not limited thereto.

[0143] – In case the BSF supports PCF discovery for multiple UEs, a UE ID list / group ID is included.

[0144] - In case the BSF does not support PCF discovery for multiple UEs, the UE ID is included. In this case, steps 415 and 420 may be repeated multiple times depending on the number of UEs.

[0145] In step 420, in case the message received in step 415 includes a UE ID list or a group ID, the BSF may include UE-specific serving PCF addresses for all corresponding UEs in a response message sent to the NEF.

[0146] In the case that the message received in step 415 includes a UE ID, the BSF may include the serving PCF address of the corresponding UE in the response message sent to the NEF.

[0147] In step 425 , based on the information included in the message received in step 420 , the NEF may have PCF address information and information about a UE list corresponding to each PCF address.

[0148] The NEF may include the following information in the message sent to the PCF. However, the present disclosure is not limited thereto.

[0149] - S-NSSAI, DNN, UE ID, reference ID

[0150] In step 430, if the UDR has obtained the reference ID in step 405, or if the message received in step 425 includes the reference ID, a query message may be sent to the UDR to obtain the corresponding data delivery policy. The message includes the reference ID and may include information indicating a data set and a data subset corresponding to the policy data and the data delivery policy (e.g., a background data delivery policy or a scheduled data delivery policy with QoS requirements).

[0151] In step 435, if the message received in step 430 includes a reference ID, the UDR may include the corresponding data transmission policy information in a response message sent to the PCF. The data transmission policy may include the following information. However, the present disclosure is not limited thereto.

[0152] - ASP Identifier: refers to the identifier of the Application Service Provider (ASP).

[0153] - Number of UEs: refers to the number of UEs to which the traffic of small applications is expected to be sent.

[0154] - Volume per UE: refers to the amount of data to be sent to each UE.

[0155] - Expected time window: includes information about the time window during which the applet's traffic is expected to be sent.

[0156] - External group identifier, internal group identifier, UE ID list: refers to information used to identify the UE to which the data delivery policy will be applied. An externally used group identifier, an internally used group identifier, or a terminal identifier list may be used.

[0157] - Network area information: refers to information about the area where data transmission is expected to occur. Geographic information may be included.

[0158] - Notification Request: Parameter used to request the NEF to send a data transfer warning notification to the AF (e.g., to notify the AF in case of a data transfer performance degradation).

[0159] - MAC address or IP triplet of the application server: This refers to the MAC address (for example, Ethernet MAC address) or IP information (for example, the server's IP address, port number, and protocol information) used to identify the application server.

[0160] - Separate QoS flow indication: During data transfer, this parameter is used to request the use of a separate QoS flow for data transfer. For example, in the case of federated learning traffic, a separate QoS flow for this traffic can be generated and used (i.e., this QoS flow is not shared with traffic from other applications).

[0161] - QoS related information: refers to the QoS information required for data transmission, etc. Minimum bit rate, bit rate difference between QoS flows, maximum delay, etc. may be included.

[0162] - QoS Reference ID: may include a value or information indicating a standardized 5QI or a predefined 5QI (ie, a 5QI value indicating a specific QoS feature pre-stored in the RAN).

[0163] In step 440 , the PCF may generate new PCC rules based on the information included in the data delivery policy received in step 435 , or update existing PCC rules.

[0164] The PCF may generate a service description filter (SDF) based on the MAC address or IP triplet of the application server included in the data delivery policy.

[0165] If the data delivery policy includes a separate binding indication, or if the 5QI in the PCC rule indicates a specific value, the PCF may determine that the corresponding PCC rule is bound to a separate QoS flow. This indicator may be included in the PCC rule or may be included as a separate parameter in the message sent to the SMF in step 445.

[0166] The message sent by PCR to SMF may include the following information:

[0167] SM policy association ID, PCC rules, and separate binding instructions

[0168] In step 450, the SMF may send a response message to the PCF.

[0169] In step 455, the SMF may perform binding on the PCC rule received in step 445 within the PDU session corresponding to the SM policy association ID in the message received from the PCF in step 445. In the case where the message received in step 445 includes a separate binding indication, even if a QoS flow with the same parameters as those included in the PCC rule exists in the PDU session, the SMF may generate a new QoS flow instead of using the same QoS flow. Specifically, the SMF may include the QoS profile generated based on the corresponding PCC rule in a message sent to the base station (i.e., radio access network (RAN)), and may include the generated QoS profile in a message sent to the UE.

[0170] Figure 5 The structure of a base station according to various embodiments of the present disclosure is shown.

[0171] refer to Figure 5 , the base station may include a transceiver 510, a controller 520, and a storage component 530. The transceiver 510, the controller 520, and the storage component 530 may operate according to the communication method of the above-mentioned base station. The network device may also correspond to the structure of the base station. However, the components of the base station are not limited to the above examples. For example, the base station may include a greater or lesser number of components than the above-mentioned components. For example, the base station may include a transceiver 510 and a controller 520. In addition, the transceiver 510, the controller 520, and the storage component 530 may be implemented in the form of a single chip.

[0172] The transceiver 510 generally refers to a base station receiver and a base station transmitter, and can transmit and receive signals with a UE, other base stations, and other network devices. The transmitted and received signals may include control information and data. The transceiver 510 can transmit, for example, system information, synchronization signals, or reference signals to the UE. To this end, the transceiver 510 may include an RF transmitter configured to up-convert and amplify the frequency of transmitted signals, an RF receiver configured to perform low-noise amplification and down-convert the frequency of received signals, and the like. However, this is merely an embodiment of the transceiver 510, and the components of the transceiver 510 are not limited to an RF transmitter and an RF receiver. The transceiver 510 may include a wired or wireless transceiver and may include various components for transmitting and receiving signals. Furthermore, the transceiver 510 may receive signals via a communication channel (e.g., a radio channel), output them to the controller 520, and transmit signals output from the controller 520 via the communication channel. In addition, the transceiver 510 may receive a communication signal, output it to the processor, and transmit the signal output from the processor to a UE, other base stations, or other network entities through a wired / wireless network.

[0173] The storage component 530 can store programs and data required for base station operation. In addition, the storage component 530 can store control information or data included in signals acquired by the base station. The storage component 530 can include storage media such as ROM, RAM, hard disk, CD-ROM, and DVD, or a combination of storage media. In addition, the storage component 530 can store at least one of information transmitted / received by the transceiver 510 and information generated by the controller 520.

[0174] As used herein, the controller 520 can be defined as a circuit, an application-specific integrated circuit, or at least one processor. The processor may include a communication processor (CP) that performs communication control and an application processor (AP) that controls upper layers such as application programs. The controller 520 can control the overall operation of the base station according to the embodiments of the present disclosure. For example, the controller 520 can control the signal flow between various modules to perform operations according to the above-described flowchart.

[0175] Figure 6 The structure of a UE according to various embodiments of the present disclosure is shown.

[0176] refer to Figure 6, the UE may include a transceiver 610, a controller 620, and a storage component 630. The transceiver 610, the controller 620, and the storage component 630 may operate according to the communication method of the UE described above. The components of the UE are not limited to the above examples. For example, the UE may include a greater or lesser number of components than the above components. For example, the UE may include the transceiver 610 and the controller 620. In addition, the transceiver 610, the controller 620, and the storage component 630 may be implemented in the form of a single chip.

[0177] The transceiver 610 generally refers to the UE receiver and UE transmitter, and can transmit and receive signals with the base station, other UEs, and other network entities. Signals transmitted and received with the base station may include control information and data. The transceiver 610 may, for example, receive system information, synchronization signals, or reference signals from the base station. To this end, the transceiver 610 may include an RF transmitter configured to up-convert and amplify the frequency of transmitted signals, an RF receiver configured to perform low-noise amplification and down-convert received signals, and the like. However, this is merely an embodiment of the transceiver 610, and the components of the transceiver 610 are not limited to an RF transmitter and an RF receiver. Furthermore, the transceiver 610 may include a wired or wireless transceiver and may include various components for transmitting and receiving signals. Furthermore, the transceiver 610 may receive signals via a radio channel, output them to the controller 620, and transmit signals output from the controller 620 via a radio channel. Furthermore, the transceiver 610 may receive communication signals, output them to a processor, and transmit signals output from the processor to network entities via a wired or wireless network.

[0178] The storage component 630 can store programs and data required for UE operation. In addition, the storage component 630 can store control information or data included in the signal obtained by the UE. The storage component 630 can include a storage medium such as ROM, RAM, hard disk, CD-ROM and DVD, or a combination of storage media.

[0179] As used herein, the controller 620 can be defined as a circuit, an application-specific integrated circuit, or at least one processor. The processor may include a communication processor (CP) that performs communication control and an application processor (AP) that controls upper layers such as application programs. The controller 620 may control the overall operation of the UE according to the embodiments of the present disclosure. For example, the controller 620 may control the signal flow between various modules to perform operations according to the above-described flowchart.

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

[0181] When the method is implemented via 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 may be configured to be executed by one or more processors within an electronic device. At least one program includes instructions that cause the electronic device to perform the method according to the various embodiments of the present disclosure as defined in the appended claims and / or disclosed herein.

[0182] These programs (software modules or software) may be stored in non-volatile memory, including random access memory and flash memory, read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic disk storage, compact disc-ROM (CD-ROM), digital versatile disc (DVD) or other types of optical storage devices or magnetic tape cassettes. Alternatively, any combination of some or all of them may form the memory in which the programs are stored. Furthermore, a plurality of such memories may be included in the electronic device.

[0183] Furthermore, the program may be stored on an attachable storage device that is accessible to the electronic device via a communication network, such as the Internet, an intranet, a local area network (LAN), a wide LAN (WLAN), and a storage area network (SAN), or a combination thereof. Such a storage device may be connected to the electronic device via an external port. Furthermore, a separate storage device on a communication network may be connected to the portable electronic device.

[0184] In the above detailed embodiments of the present disclosure, the elements included in the present disclosure are expressed in the singular or plural, depending on the detailed embodiment presented. However, the singular form or plural form is appropriately selected for the convenience of description for the presented situation, and the present disclosure is not limited to the elements expressed in the singular or plural. Therefore, an element expressed in the plural may also include a single element, or an element expressed in the singular may also include multiple elements.

[0185] Although specific embodiments have been described in the detailed description of the present disclosure, it is apparent that various modifications and changes can be made thereto without departing from the scope of the present disclosure. Therefore, the scope of the present disclosure should not be defined as being limited to the embodiments set forth herein, but should be defined by the appended claims and their equivalents.

Claims

1. A method performed by a network exposure function (NEF) entity in a wireless communication system, the method comprising: receiving a first message from an application function (AF) entity, the first message requesting negotiation of a planned data transfer with QoS (PDTQ) policy; Sending a second message to a policy control function (PCF) entity based on the first message, wherein the second message requests identification of the PDTQ policy; receiving a third message from the PCF entity, the third message including information related to at least one PDTQ policy identified by the PCF entity; as well as The information related to at least one identified PDTQ policy is sent to the AF entity.

2. The method according to claim 1, further comprising: receiving a fourth message from the AF entity, the fourth message including a PDTQ policy and a PDTQ policy reference ID selected by the AF entity; as well as Sending a selected PDTQ policy to the PCF entity, The first message includes information requesting negotiation of the PDTQ policy, and The information requesting negotiation of the PDTQ policy includes at least one of a separate QoS flow indication, a QoS reference ID, and QoS related information.

3. The method according to claim 1, wherein The information related to the at least one PDTQ policy includes a policy reference ID for each of the at least one PDTQ policy identified by the PCF entity, and information on a recommended usage time of the PDTQ policy.

4. The method according to claim 1, wherein The PDTQ policy and the PDTQ policy reference ID selected by the AF entity are stored by the PCF entity, or are transferred from the PDF entity to a unified data repository UDR entity and stored therein.

5. A method performed by a policy control function (PCF) entity in a wireless communication system, the method comprising: receiving a first message from a network open function NEF entity, the first message requesting identification of a planned data transfer with QoS (PDTQ) policy according to a request of an application function AF entity; Sending a second message to a unified data repository UDR entity, wherein the second message requests a pre-stored PDTQ policy and information for identifying the PDTQ policy of the AF entity; receiving a third message from the UDR entity, the third message including the pre-stored PDTQ policy and the information for identifying the PDTQ policy of the AF entity; identifying at least one PDTQ policy based on the third message; as well as Sending a fourth message to the NEF entity, the fourth message including at least one identified PDTQ policy and information related to the at least one identified PDTQ policy, The PDTQ policy indicates at least one QoS policy that can be provided to a third party.

6. The method according to claim 5, further comprising: receiving, through the NEF entity, a fifth message from the AF entity, the fifth message including a PDTQ policy and a PDTQ policy reference ID selected by the AF entity; storing a PDTQ policy and the PDTQ policy reference ID selected by the AF entity based on the fifth message; as well as A sixth message is sent to the UDR entity, where the sixth message includes a PDTQ policy selected by the AF entity and the PDTQ policy reference ID.

7. The method according to claim 5, wherein: The first message includes information requesting negotiation of the PDTQ policy, and The information requesting negotiation of the PDTQ policy includes at least one of a separate QoS flow indication, a QoS reference ID, and QoS related information.

8. The method according to claim 5, wherein The information related to the at least one PDTQ policy includes a policy reference ID of each PDTQ policy in the at least one PDTQ policy identified by the PCF entity, and information on a recommended usage time of the PDTQ policy.

9. A network open function (NEF) entity in a wireless communication system, the NEF entity comprising: at least one transceiver; as well as a controller coupled to the at least one transceiver, Wherein, the controller is configured as follows: receiving a first message from an application function (AF) entity, the first message requesting negotiation of a planned data transfer with QoS (PDTQ) policy; Sending a second message to a policy control function (PCF) entity based on the first message, wherein the second message requests identification of the PDTQ policy; receiving a third message from the PCF entity, the third message including information related to at least one PDTQ policy identified by the PCF entity; and The information related to at least one identified PDTQ policy is sent to the AF entity.

10. The UPF entity according to claim 9, wherein: The controller is further configured to: receiving a fourth message from the AF entity, the fourth message including a PDTQ policy and a PDTQ policy reference ID selected by the AF entity; as well as Sending a selected PDTQ policy to the PCF entity, The first message includes information requesting negotiation of the PDTQ policy, and The information requesting negotiation of the PDTQ policy includes at least one of a separate QoS flow indication, a QoS reference ID, and QoS related information.

11. The UPF entity according to claim 9, wherein: The information related to the at least one PDTQ policy includes a policy reference ID for each of the at least one PDTQ policy identified by the PCF entity, and information on a recommended usage time of the PDTQ policy.

12. The UPF entity according to claim 9, wherein: The PDTQ policy and the PDTQ policy reference ID selected by the AF entity are stored by the PCF entity, or are transferred from the PDF entity to the UPF entity and stored therein.

13. A policy control function (PCF) entity in a wireless communication system, the PCF entity comprising: at least one transceiver; as well as a controller coupled to the at least one transceiver, Wherein, the controller is configured as follows: receiving a first message from a network open function NEF entity, the first message requesting identification of a planned data transfer with QoS (PDTQ) policy according to a request of an application function AF entity; Sending a second message to a unified data repository UDR entity, wherein the second message requests a pre-stored PDTQ policy and information for identifying the PDTQ policy of the AF entity; receiving a third message from the UDR entity, the third message including the pre-stored PDTQ policy and information for identifying the PDTQ policy of the AF entity; identifying at least one PDTQ policy based on the third message; and Sending a fourth message to the NEF entity, the fourth message including at least one identified PDTQ policy and information related to the at least one identified PDTQ policy, The PDTQ policy indicates at least one QoS policy that can be provided to a third party.

14. The PCF entity according to claim 13, wherein: The controller is further configured to: receiving, through the NEF entity, a fifth message from the AF entity, the fifth message including a PDTQ policy and a PDTQ policy reference ID selected by the AF entity; storing a PDTQ policy and the PDTQ policy reference ID selected by the AF entity based on the fifth message; as well as A sixth message is sent to the UDR entity, where the sixth message includes a PDTQ policy selected by the AF entity and the PDTQ policy reference ID.

15. The method according to claim 13, wherein The first message includes information requesting negotiation of the PDTQ policy, The information requesting negotiation of the PDTQ policy includes at least one of a separate QoS flow indication, a QoS reference ID, and QoS related information, and The information related to the at least one PDTQ policy includes a policy reference ID of each PDTQ policy in the at least one PDTQ policy identified by the PCF entity, and information about a recommended usage time of the PDTQ policy.

Images