WO2022160092A1

WO2022160092A1 - Improvement of dns configuration for applications

Info

Publication number: WO2022160092A1
Application number: PCT/CN2021/073768
Authority: WO
Inventors: Tingfang Tang
Original assignee: Lenovo Beijing Ltd
Current assignee: Lenovo Beijing Ltd
Priority date: 2021-01-26
Filing date: 2021-01-26
Publication date: 2022-08-04
Anticipated expiration: 2023-07-26

Abstract

Method and apparatus for improvement of DNS configuration for applications are disclosed. A method performed at a UE comprises receiving DNS information for the UE or for a PDU session, wherein the DNS information identifies and configures one or more DNS servers for at least one application; and selecting a DNS server for DNS resolution for the at least one application based on the received DNS information.

Description

IMPROVEMENT OF DNS CONFIGURATION FOR APPLICATIONS

FIELD

The subject matter disclosed herein generally relates to wireless communications, and more particularly relates to improvement of DNS configuration for applications.

BACKGROUND

The following abbreviations are herewith defined, at least some of which are referred to within the following description: New Radio (NR) , Very Large Scale Integration (VLSI) , Random Access Memory (RAM) , Read-Only Memory (ROM) , Erasable Programmable Read-Only Memory (EPROM or Flash Memory) , Compact Disc Read-Only Memory (CD-ROM) , Local Area Network (LAN) , Wide Area Network (WAN) , User Equipment (UE) , Evolved Node B (eNB) , Next Generation Node B (gNB) , Uplink (UL) , Downlink (DL) , Central Processing Unit (CPU) , Graphics Processing Unit (GPU) , Field Programmable Gate Array (FPGA) , Orthogonal Frequency Division Multiplexing (OFDM) , Radio Resource Control (RRC) , User Entity/Equipment (Mobile Terminal) , DN Access Identifier (DNAI) , 5G core (5GC) , Protocol Data Unit (PDU) , PDU Session Anchor (PSA) , uplink classifier (UL classifier or ULCL) , Domain Name System (DNS) , Local DNS Resolver (LDNSR) , Edge Application Server (EAS) , Session Management (SM) , Session Management Function (SMF) , Protocol Configuration Options (PCO) , Service Provider (SP) , Multi-access Edge Computing (MEC) , data network (DN) , Branching Point (BP) , Domain Name System (DNS) , Policy Control Function (PCF) , Access and Mobility Management Function (AMF) , Application Function (AF) , Fully Qualified Domain Name (FQDN) , UE Route Selection Policy (URSP) , Service and Session Continuity (SSC) , User Plane Function (UPF) , Application Server (AS) .

Edge platform is deployed for providing differentiated application services. Some applications can be accessed via the edge platform from one or more DNAIs. Other applications can be accessed via the public internet (or central DN) . And some applications can be accessed via both the edge platform and public internet (or central DN) . 5GC supports three connectivity models to enable edge computing: 1) Distributed Anchor Point, 2) Session Breakout, and 3) Multiple PDU sessions, as illustrated in Figure 1. In 1) Distributed Anchor Point, multiple PDU sessions are used. In 2) Session Breakout, a PDU session may be associated with multiple PDU session anchors (PSAs) , in which uplink classifier (UL classifier or ULCL) or IPv6 multi-homing is used. In 3) Multiple PDU sessions, multiple PDU sessions are used.

DNS servers are used to resolve the DNS request and discover the IP address of one suitable Application Server considering the Edge Computing deployment for applications. The 5GC can use LDNSR to decide and forward DNS message to the local DNS server or central DNS server based on related information. The DNS servers can be deployed locally and centrally. LDNSR is an abbreviation of local DNS resolver and acts as an enhanced DNS forwarder. LDNSR is a new function that allows coordination of the EAS Discovery using DNS and the 5GC connectivity. LDNSR facilitates that it is possible to select the DNS server to resolve the DNS query into the EAS closer to the edge in which the UE is deployed In addition, LDNSR may provide information to trigger dynamic insertion of ULCL or BP or local PSA.

The options 1-3 for the EAS discovery using LDNSR are described in Figure 2.

Option 1: LDNSR is configured as DNS server to the UE during PDU session establishment by SMF via PCO. LDNSR forwards the received UL DNS query, inserting an ECS option, to C-DNS server.

Option 2: LDNSR is configured as DNS server to the UE during PDU session establishment by SMF via PCO. LDNSR forwards the received UL DNS query to L-DNS resolver.

Option 3: The L-DNS resolver (which is different from LDNSR) or L-DNS server can be configured to UE as DNS server for the PDU session. For example, the SPs prefer to own the MEC hosts including edge DNS server as well rather than using local DNS services provided by the network providers.

As mentioned in the above model 2) , a PDU Session can be associated with multiple PSA anchors. Accordingly, the PDU session may be associated with multiple IPv6 prefixes. For example, the PDU session may be referred to as multi-homed PDU Session. The multi-homed PDU Session provides access to the Data Network via more than one PDU Session Anchor in order to support selective traffic routing to the DN. According to the existing solutions, before the local BP or local PSA insertion, the LDNSR located centrally can be configured to the UE as DNS server, and the DNS query message is sent to the LDNSR. The DNS response message, if pointed to the local application server, can trigger the local BP or local PSA insertion. After the local BP or local PSA insertion, there are both user plane paths to central DN and local DN.

However, there are following problems for the PDU session with multiple PSA anchors for the case that some applications can be accessed via the central DN and the other applications can be accessed the other DN e.g. local DN, and some applications can be accessed via both the central DN and the local DN.

If the central LDNSR is kept as DNS server after the local BP or local PSA insertion, in order to avoid the DNS spoofing, all subsequent DNS queries are still sent the central LDNSR even if the related DNS server is deployed in local DN and there is local user plane path. It will increase the difficulty and decrease the efficiency for the DNS handling for the DNS queries terminating at the local DNS server.

If the local DNS server or local DNS resolver is configured to the UE, after the local BP or local PSA insertion, in order to avoid the DNS spoofing, all subsequent DNS queries are sent the local DNS server or local DNS resolver even if the related DNS server is deployed in central DN. Especially in the case that the local DNS server can only process the DNS messages for the application deployed within its own edge environment or the local DN has no direct connection with the central DN, it will increase the difficulty and decrease the efficiency for the DNS handling for the DNS queries terminating at the central DNS server.

Therefore, for the PDU session with multiple PSA anchors, for the case that some applications can be accessed via the central DN and the other applications can be accessed via the other DN e.g. local DN, and some applications can be accessed via both the central DN and the local DN, when each deployed DN has its own preferred DNS server for DNS resolving, it is efficient to deliver the DNS queries to the local DN using local user plane path and to the central DN using central user plane path, so that the DNS server configured to the UE should be set accordingly and let the UE select the appropriate DNS server for DNS resolution.

An existing “5GC support for UE selection of the DNS to use” is specified in clause 6.13 of 3GPP TR 23.748, in which the “DN priorities for appDomains” is configured by AF.The “DN priorities for appDomains” may be used to set the rule precedence of URSP rules or DNS priorities. However, the URSP rules cannot be used for choosing appropriate DNS servers for the PDU session with multiple PSA anchors. The DNS priorities provide DNS priorities per (DNN, S-NSSAI) in 3 ways: 1) via NAS PCO; 2) via Router Advertisement per IETF RFC 8106; and 3) DHCP RDNSS option. In 1) via NAS PCO, the DNS server (list) is configured per UE node. So, it relies on UE implementation for DNS sever selection and the UE may inappropriately select local DNS for central applications and/or central DNS server for local applications due to lack of information for making choice. In 2) via Router Advertisement, RDNSS and DNSSL options are used, in which there is no preference information for one application. So, it relies on UE implementation for DNS sever selection. The central DNS server maybe selected even if the application is relocated into the local DN with local DNS server for resolution and vice versa. In 3) DHCP RDNSS option, DNS-recursive-name-server, the Domains and networks and the DHCP option preference field are provided. However, the central DNS server maybe selected even if the application is relocated into the local DN with local DNS server for resolution and vice versa. As a whole, the DNS priorities do not have information for one application that needs different DNS servers for DNS resolution.

The purpose of the present invention is to improve DNS configuration for applications.

BRIEF SUMMARY

Method and apparatus for improvement of DNS configuration for applications are disclosed.

In one embodiment, a method comprises receiving DNS information for the UE or for a PDU session, wherein the DNS information identifies and configures one or more DNS servers for at least one application; and selecting a DNS server for DNS resolution for the at least one application based on the received DNS information. For example, when a DNS query for the application deployed centrally is triggered, the DNS query is sent to a C-DNS server or LDNSR; and when a DNS query for the application deployed locally is triggered, the DNS query is sent to an L-DNS server or an L-DNS resolver or the LDNSR.

In one embodiment, the DNS information further includes validation criteria for the one or more DNS servers. In another embodiment, the DNS information further includes precedence for the one or more DNS servers. The method may further comprise transmitting an indication of UE support for DNS selection policy in UE registration procedure and/or in PDU session establishment procedure. During the PDU session establishment procedure or due to insertion of a local UPF, the method may further comprise receiving updated DNS information. The DNS information can be received as a part of URSP rule or as a separate rule.

In another embodiment, a method performed at a PCF comprises: constructing DNS information for a UE or for a PDU session, wherein the DNS information i identifies and configures one or more DNS servers; and transmitting the DNS information.

In some embodiment, the DNS information further includes validation criteria for the one or more DNS servers. In some other embodiment, the DNS information further includes precedence for the one or more DNS servers. The DNS information may be constructed based on DNS information configured locally or dynamically from AF. The method may further comprise receiving an indication of UE support for DNS selection policy in UE registration procedure and/or in PDU session establishment procedure. During the PDU session establishment procedure or due to insertion of a local UPF, the method may further comprise constructing updated DNS information based on additional DNS information, and transmitting the updated DNS information. The DNS information can be transmitted as a part of URSP rule or as a separate rule.

In some embodiment, a method performed at a SMF comprises: constructing DNS information for PDU session based on at least one of DNS information configured locally, DNS information decided locally and DNS information received from PCF, wherein the DNS information for PDU session identifies and configures one or more DNS servers; and transmitting the DNS information for PDU session.

In one embodiment, a UE comprises a processor; and a receiver coupled to the processor, the receiver being configured to receive DNS information for the UE or for a PDU session, wherein the DNS information identifies and configures one or more DNS servers for at least one application, wherein the processor is configured to select a DNS server for DNS resolution for an application based on the received DNS information.

In another embodiment, the network node PCF comprises a processor configured to construct DNS information for a UE or for a PDU session, wherein the DNS information identifies and configures one or more DNS servers; and a transmitter coupled to the processor, the transmitter being configured to transmit the DNS information.

In yet another embodiment, the network node SMF comprises a processor configured to construct DNS information for PDU session based on at least one of DNS information configured locally, DNS information decided locally and DNS information received from PCF, wherein the DNS information for PDU session identifies and configures one or more DNS servers; and a transmitter coupled to the processor, the transmitter being configured to transmit the DNS information for the PDU session.

BRIEF DESCRIPTION OF THE DRAWINGS

A more particular description of the embodiments briefly described above will be rendered by reference to specific embodiments that are illustrated in the appended drawings. Understanding that these drawings depict only some embodiments, and are not therefore to be considered to be limiting of scope, the embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

Figure 1 illustrates 5GC connectivity models for edge computing;

Figure 2 illustrates options for EAS discovery using LDSNR for PDU session breakout;

Figure 3 illustrates procedures according to a first embodiment;

Figure 4 illustrates procedures according to a second embodiment;

Figure 5 illustrates procedures according to a third embodiment;

Figure 6 illustrates is a schematic flow chart diagram illustrating an embodiment of a method;

Figure 7 is a schematic flow chart diagram illustrating a further embodiment of a method;

Figure 8 is a schematic flow chart diagram illustrating a still further embodiment of a method;

Figure 9 is a schematic block diagram illustrating an apparatus according to one embodiment; and

Figure 10 is a schematic block diagram illustrating another apparatus according to one embodiment.

DETAILED DESCRIPTION

As will be appreciated by one skilled in the art that certain aspects of the embodiments may be embodied as a system, apparatus, method, or program product. Accordingly, embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc. ) or an embodiment combining software and hardware aspects that may generally all be referred to herein as a “circuit” , “module” or “system” . Furthermore, embodiments may take the form of a program product embodied in one or more computer readable storage devices storing machine-readable code, computer readable code, and/or program code, referred to hereafter as “code” . The storage devices may be tangible, non-transitory, and/or non-transmission. The storage devices may not embody signals. In a certain embodiment, the storage devices only employ signals for accessing code.

Certain functional units described in this specification may be labeled as “modules” , in order to more particularly emphasize their independent implementation. For example, a module may be implemented as a hardware circuit comprising custom very-large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.

Modules may also be implemented in code and/or software for execution by various types of processors. An identified module of code may, for instance, include one or more physical or logical blocks of executable code which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but, may include disparate instructions stored in different locations which, when joined logically together, include the module and achieve the stated purpose for the module.

Indeed, a module of code may contain a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules and may be embodied in any suitable form and organized within any suitable type of data structure. This operational data may be collected as a single data set, or may be distributed over different locations including over different computer readable storage devices. Where a module or portions of a module are implemented in software, the software portions are stored on one or more computer readable storage devices.

Any combination of one or more computer readable medium may be utilized. The computer readable medium may be a computer readable storage medium. The computer readable storage medium may be a storage device storing code. The storage device may be, for example, but need not necessarily be, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

A non-exhaustive list of more specific examples of the storage device would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, random access memory (RAM) , read-only memory (ROM) , erasable programmable read-only memory (EPROM or Flash Memory) , portable compact disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium may be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

Code for carrying out operations for embodiments may include any number of lines and may be written in any combination of one or more programming languages including an object-oriented programming language such as Python, Ruby, Java, Smalltalk, C++, or the like, and conventional procedural programming languages, such as the "C" programming language, or the like, and/or machine languages such as assembly languages. The code may be executed entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the very last scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN) , or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider) .

Reference throughout this specification to “one embodiment” , “an embodiment” , or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, appearances of the phrases “in one embodiment” , “in an embodiment” , and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment, but mean “one or more but not all embodiments” unless expressly specified otherwise. The terms “including” , “comprising” , “having” , and variations thereof mean “including but are not limited to” , unless otherwise expressly specified. An enumerated listing of items does not imply that any or all of the items are mutually exclusive, otherwise unless expressly specified. The terms “a” , “an” , and “the” also refer to “one or more” unless otherwise expressly specified.

Furthermore, described features, structures, or characteristics of various embodiments may be combined in any suitable manner. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of embodiments. One skilled in the relevant art will recognize, however, that embodiments may be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid any obscuring of aspects of an embodiment.

Aspects of different embodiments are described below with reference to schematic flowchart diagrams and/or schematic block diagrams of methods, apparatuses, systems, and program products according to embodiments. It will be understood that each block of the schematic flowchart diagrams and/or schematic block diagrams, and combinations of blocks in the schematic flowchart diagrams and/or schematic block diagrams, can be implemented by code. This code may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which are executed via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the schematic flowchart diagrams and/or schematic block diagrams for the block or blocks.

The code may also be stored in a storage device that can direct a computer, other programmable data processing apparatus, or other devices, to function in a particular manner, such that the instructions stored in the storage device produce an article of manufacture including instructions which implement the function specified in the schematic flowchart diagrams and/or schematic block diagrams block or blocks.

The code may also be loaded onto a computer, other programmable data processing apparatus, or other devices, to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the code executed on the computer or other programmable apparatus provides processes for implementing the functions specified in the flowchart and/or block diagram block or blocks.

The schematic flowchart diagrams and/or schematic block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of apparatuses, systems, methods and program products according to various embodiments. In this regard, each block in the schematic flowchart diagrams and/or schematic block diagrams may represent a module, segment, or portion of code, which includes one or more executable instructions of the code for implementing the specified logical function (s) .

It should also be noted that in some alternative implementations, the functions noted in the block may occur out of the order noted in the Figures. For example, two blocks shown in succession may substantially be executed concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more blocks, or portions thereof, to the illustrated Figures.

Although various arrow types and line types may be employed in the flowchart and/or block diagrams, they are understood not to limit the scope of the corresponding embodiments. Indeed, some arrows or other connectors may be used to indicate only the logical flow of the depicted embodiment. For instance, an arrow may indicate a waiting or monitoring period of unspecified duration between enumerated steps of the depicted embodiment. It will also be noted that each block of the block diagrams and/or flowchart diagrams, and combinations of blocks in the block diagrams and/or flowchart diagrams, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and code.

The description of elements in each Figure may refer to elements of proceeding figures. Like numbers refer to like elements in all figures, including alternate embodiments of like elements.

According to a first embodiment, the DNS server is configured via DNS selection rule for UE. The first embodiment assumes that the DNS server information can be gotten by the PCF.

In step 300, UE initiates registration with the network (e.g. AMF) . By default, a UE capability “UE support for DNS selection policy” is supported by the UE. Alternatively, the UE capability “UE support for DNS selection policy” can be optionally supported by the UE. In the latter condition, an indication of UE support for DNS selection policy can be included in the registration procedure.

In step 301, the AMF makes decision to establish UE policy association.

In step 302, the AMF sends a UE policy control create request (e.g. Npcf_UEPolicyControl Create Request) to the PCF. The indication of UE support for DNS selection policy, if received in step 300, is included in the UE policy control create request.

In step 302a, the PCF makes policy decision for the DNS information for the UE. The PCF constructs the DNS information for the UE based on DNS information configured locally or dynamically, and optionally the information from the SMF (e.g. if the indication of UE support for DNS selection policy is included in the message sent from the SMF) . The DNS information configured locally means the DNS information that has been configured onto the PCF. The DNS information configured dynamically means that the PCF may obtain the DNS information from AF (not shown in Figure 3) via existing procedure such as traffic routing information provisioning procedure or parameter provisioning procedure, etc.

The DNS information includes a list of DNS servers for the applications, e.g. FQDNs. Optionally, the DNS information further includes related validation criteria, which represents the criteria to be considered when the DNS server is selected. For example, for the case that the FQDN for one application should be resolved by DNS server 1 while the application and related DNS server are deployed centrally and DNS server 2 while the application and related DNS server are deployed locally, the DNS server 2 should be present with the validation criteria, e.g. location criteria indicating a local service area.

In step 303, the PCF sends a UE policy control create response (e.g. Npcf_UEPolicyControl_Create Response) to the AMF. The DNS information for the UE can be included in the UE policy control create response as part of URSP rule or as a separate rule.

If the DNS information for the UE is included as part of URSP rule, the DNS information for the UE can be treated as a kind of traffic that needs to be routed. The following Table 1 gives example of the structure of the DNS information.

Table 1: UE Route Selection Policy (URSP) Rule

It can be seen from Table 1 that the “DNS Server Selection descriptors” identifies DNS information for the identified traffic; the “List of DNS Servers” identifies a list of addresses of DNS servers for the identified traffic” ; and the “Location Criteria” (which is an example of related validation criteria) identifies the UE location where the matching DNS server is allowed. The DNS server is not considered to be used if the UE location does not match the location criteria. Optionally, a DNS selection descriptor precedence may be included to determine the order of the DNS Server selection rules enforced in the UE.

The URSP rule includes “List of Route Selection Descriptors” . A “Route Selection Descriptor” contains Route Selection Validation Criteria. As an alternatively way of including the DNS information for the UE as part of URSP rule, the DNS information for the UE can be described as part of Route Selection Descriptor, sharing the same Route Selection Validation Criteria, as shown in Table 2

Table 2: Route Selection Descriptor

As can be seen from Table 2, in the “Route Selection Descriptor” , the “List of DNS Servers” identifies a list of addresses of DNS servers for the identified traffic. The “Route Selection Validation Criteria” represents the related validation criteria to be considered. The “time window” and “location criteria” are examples of validation criteria.

If the DNS information is included as a separate rule (e.g. UE DNS server Selection Policy Rule) , the DNS server (s) for the application (s) (e.g. FQDNs for the domain descriptors) are included in the separate rule. The separate rule optionally includes the validation criteria (e.g., the location criteria) , and the rule precedence. Table 3 gives an example of the separate rule (e.g. UE DNS server Selection Policy Rule) .

Table3 : UE DNS server Selection Policy Rule

In step 304, UE Configuration Update procedure is used to deliver the DNS information for the UE to the UE. For example, the C-DNS server is configured for the centrally deployed applications, and L-DNS server is configured for the (or some) locally deployed applications within the DNS selection policy.

In step 305, the PDU Session is established with C-UPF.

In step 306a, DNS Query for central application, supposed to be resolved in C-DNS server, is triggered in the UE. In step 306b, C-DNS server is selected as the DNS server for the DNS Query based on the DNS information for the UE received in step 304. The address of C-DNS server is used as the DA for the DNS query message. In step 306c, The DNS query is sent to the C-DNS server. In step 306d, DNS response is received.

In step 307, local UPF insertion to access local DN happens. For example, a PDU session needs to access the local DN (e.g. the MEC) , which leads to that a local PSA is inserted (replaced) to access the local DN (e.g. the MEC) .

In step 308a, DNS Query for local application, supposed to be resolved in L-DNS server, is triggered in the UE. In step 308b, the related L-DNS server is selected as the DNS server for the DNS Query based on the DNS information received in step 304. The address of L-DNS server is used as the DA for the DNS query message. In step 308c, DNS query is sent to the L-DNS server for resolution. In step 308d, DNS response is received from the L-DNS server.

It can be seen from the first embodiment that the PCF decides the DNS information for the UE. This is triggered in the UE registration procedure. Alternatively, it can be triggered by any related policy update conditions. The DNS information for the UE includes different DNS servers (e.g. C-DNS server and L-DNS servers) for different applications (e.g. FQDNs) . For example, in one multi-homed PDU session, C-DNS server is determined as the DNS server for central applications, and L-DNS server is determined as the DNS server for local applications. Optionally, the DNS information further includes related validation criteria and the precedence for applying the DNS information. In the first embodiment, the LDNSR is not deployed.

According to a second embodiment, the DNS server involving LDNSR is configured via DNS selection rule for UE. The second embodiment assumes that the DNS server information for applications is configured to the 5GC (e.g. to SMF or PCF) locally or dynamically; and that the LDNSR is deployed for DNS handling for the DNS message for some applications. LDNSR may have different name (s) in the future. The present application is not limited to a network node that is named as LDNSR. The present application applies to any network node that can act as DNS forwarder as described in the background part.

Steps 400 to 404 of the second embodiment are the same as steps 300 to 304 of the first embodiment. Accordingly, detailed explanations of steps 400 to 404 are omitted. After steps 400 to 404, the DNS information is configured to the UE. That is, the C-DNS server is configured for the centrally deployed applications, and L-DNS server is configured for the (or some) locally deployed applications.

In step 405, the PDU Session establishment is initiated.

In step 406, the AMF sends a PDU session create SM context request (e.g. Nsmf_PDUSession_CreateSMContext Request) to the SMF.

In step 407, the SMF selects PCF.

In

steps

408 and 409, the SMF interacts with the selected PCF for SM Policy Association Establishment. In step 408, the SMF sends a SM policy control create request (e.g. Npcf_SMPolicyControl_Create Request) to the PCF. In step 409, the PCF sends a SM policy control create response (e.g. Npcf_SMPolicyControl_Create Response) to the SMF. The response may include the DNS control information indicating whether the SMF needs to send the DNS configuration to the UE. The response may also indicate the SMF to notify additional DNS information to the PCF to update the UE policy for DNS information.

In step 410, the SMF selects C-UPF.

In step 411, the SMF selects LDNSR.

In step 412, the SMF notifies additional DNS information (e.g. which LDSNR is selected) to the PCF, e.g. if the indication to the SMF to notify additional DNS information is received in step 409. The PCF makes decision whether to update the UE policy for DNS information.

In steps 413 and 414, a PDU session establishment accept message (e.g. PDU Session Establishment Accept) is sent to the UE. For example, in step 413, the SMF sends a PDU session create SM context response (e.g. Nsmf_PDUSession_CreateSMContext Response) to the AMF; and in step 414, the AMF sends a PDU Session Establishment Accept message to the UE. If the DNS control information indicating that the SMF needs not to send the DNS configuration to the UE is received in step 409, the DNS configuration is not included in the NAS PCO.

Steps 415 to 417 are executed if the notification is received in step 412 and the PCF decides that the update of the DNS information to the UE is needed. For example, when the selected LDNSR in step 411 as the DNS server should be notified to UE, the update is needed.

In steps 415 to 417, the updated DNS information (e.g. updated DNS information for the UE) , considering the notification of LDNSR information, is delivered to the UE. For example, in step 415, a UE policy control update notify request (e.g. Npcf_UEPolicyControl_UpdateNotify Request) is sent from the PCF to the AMF; in step 416, a UE configuration update procedure is performed between the AMF and the UE so that the updated DNS information is known to the UE; and in step 417, a UE policy control update notify response (e.g. Npcf_UEPolicyControl_UpdateNotify Response) is sent from the AMF to the PCF. In the updated DNS information, LDNSR can be updated as DNS server for the applied applications which can be dedicated applications or all the applications.

When LDNSR is deployed, the DNS servers that can be chosen by the UE are LDNSR, C-DNS server and L-DNS server. Therefore, in the updated DNS information, the LDNSR can be updated for some dedicated applications or all applications. The C-DNS server and/or L-DNS server can still be chosen by the UE or replaced by the LDNSR.

In step 418a, DNS Query for central application, supposed to be handled by LDNSR and resolved in C-DNS server, is triggered in the UE. In step 418b, the LDNSR is selected as the DNS server for the DNS Query based on the received DNS information in step 416. The address of LDNSR is used as the DA for the DNS query message. In step 418c, the DNS query is sent to the LDSNR and then forwarded to the C-DNS server. In step 418d, the DNS response is sent back to the UE. If DNS Query for central application, supposed to be resolved in C-DNS server directly, is triggered in the UE, the C-DNS is selected as the DNS server for the DNS Query based on the received DNS information.

In step 419, a local UPF insertion to access local DN is triggered.

In step 420, due to the insertion of the local UPF, if the 5GC (e.g. SMF) makes decision that L-DNS server is added or updated for DNS handling for the DNS message for some (or all) local applications. The decision (e.g. the notification of L-DNS server) can be sent, as additional DNS information, to the PCF, e.g. if the indication to the SMF to notify the DNS information is received in step 409. The PCF makes decision on whether the UE policy for DNS information needs to be updated. If the update is needed (for example, the L-DNS server used for some (or all) local applications is not yet known to the UE or needs to be updated) , step 421a to 421c are executed. Otherwise, steps 421a to 421c are omitted.

In steps 421a to 421c, the updated DNS information (e.g. the updated DNS information for the UE) , considering the notification received in step 420, is delivered to the UE. For example, in step 421a, a UE policy control update notify request (e.g. Npcf_UEPolicyControl_UpdateNotify Request) is sent from the PCF to the AMF; in step 421b, a UE configuration update procedure is performed between the AMF and the UE so that the updated DNS information is known to the UE; and in step 421c, a UE policy control update notify response (e.g. Npcf_UEPolicyControl_UpdateNotify Response) is sent from the AMF to the PCF. In the updated DNS information, L-DNS server is updated as DNS server for the (or some) locally deployed applications.

In step 422a, DNS Query for local application, supposed to be resolved in L-DNS server, is triggered in the UE. In step 422b, the related L-DNS server is selected as the DNS server for the DNS Query based on the received DNS information. The address of L-DNS server is used as the DA for the DNS query message. In step 422c, DNS query is sent to the L-DNS server for resolution. In step 422d, the DNS response is received from the L-DNS server.

It can be seen from the second embodiment that the PCF decides the DNS information for the UE. This is triggered in the UE registration procedure. Alternatively, it can be triggered by any related policy update conditions with the same manner as in the first embodiment. In addition, in the second embodiment, during the PDU session establishment procedure, the DNS information for the UE can be updated, by the PCF with reference to the notification from the SMF (e.g. which LDSNR is selected) , to updated DNS information for the UE.Moreover, when a local UPF insertion to access local DN is triggered, the DNS information for the UE can be also updated, by the PCF with reference to the notification from the SMF (e.g. an L-DNS server is added or updated) , to updated DNS information for the UE. Accordingly, when a LDNSR is deployed, different DNS servers (LDNSR or C-DNS, and L-DNS server) can be determined for different applications (e.g. different for central applications and local applications) . If the DNS information related the LDNSR or L-DNS server decided by the SMF needs to be invalidated when the PDU session is released, the SMF can notify the information to the PCF and further update the DNS information for the UE to invalidate the DNS information related the LDNSR or L-DNS server decided by the SMF.

According to a third embodiment, the DNS server is configured via DNS selection rule for PDU session. The third embodiment assumes that the UE has been registered with the network (during the registration, the DNS information for the UE is not configured) , and that the DNS server information for applications is configured to the 5GC (e.g. to SMF or PCF) locally or dynamically.

In step 501, the PDU Session establishment is initiated. By default, a UE capability “UE support for DNS selection policy” is supported by the UE. Alternatively, the UE capability “UE support for DNS selection policy” can be optionally supported by the UE. In the latter condition, an indication of UE support for DNS selection policy can be included in the PDU Session establishment.

In step 502, AMF sends a PDU session create SM context request (e.g. Nsmf_PDUSession_CreateSMContext Request) to the SMF. The indication of UE support for DNS selection policy, if received in step 501, is included in the PDU session create SM context request.

In step 503, the SMF selects PCF.

In step 504, the SMF sends a SM policy control create request (e.g. Npcf_SMPolicyControl_Create Request) to the PCF. The indication of UE support for DNS selection policy, if received in step 502, is included in the SM policy control create request.

In step 504a, the PCF makes policy decision on the DNS information for the PDU session. The DNS information for the PDU session may be constructed based on the DNS information configured locally or dynamically from AF (AF is not shown in Figure 5) , and optionally the information from the SMF (e.g. an indication of UE support for DNS selection policy) .

In step 505, the PCF sends a SM policy control create response (e.g. NpcfSMPolicyControl_Create Response) to the SMF. The DNS information for the PDU session is included in the SM policy control create response. The DNS information for the PDU session can include a list of DNS servers for the applications e.g. FQDNs. Optionally, the DNS information for the PDU session further includes related validation criteria, which represents the criteria to be considered when the DNS server is selected. Optionally, the DNS information for the PDU session further includes rule precedence for determining the order of the DNS Server selection rules enforced in the UE.

In step 506, the SMF selects C-UPF.

In step 507, the SMF selects LDNSR.

In step 508, the SMF constructs the DNS information for the PDU session based on at least one of locally configured DNS information (i.e. the DNS information configured in the SMF) , locally decided DNS information (i.e. the DNS information decided by the SMF, e.g. the LDNSR information (the information about the LDNSR selected by the SMF) ) and the DNS information received from the PCF in step 505, and sends a PDU session create SM context response (e.g. Nsmf_PDUSession_CreateSMContextResponse) to the AMF. The PDU session create SM context response includes the constructed DNS information for the PDU session by the SMF. In the constructed DNS information for the PDU session by the SMF, LDNSR can be configured for DNS handling for specific applications or all the applications, C-DNS server can be configured for the centrally deployed applications, and L-DNS server can be configured for the (or some) locally deployed applications.

In step 509, the AMF sends a PDU session establishment accept message to the UE. The PDU session establishment accept message includes the DNS information for the PDU session constructed by the SMF.

In steps 510a, DNS Query for central application, supposed to be handled by LDNSR and resolved in C-DNS server, is triggered in the UE. In step 510b, the LDNSR is selected as the DNS server for the DNS Query based on the received DNS information. The address of LDNSR is used as the DA for the DNS query message. In step 510c, the DNS query is sent to the LDSNR and then forwarded to the C-DNS server. In step 510d, the DNS response is sent back to the UE. If DNS Query for central application, supposed to be resolved in C-DNS server directly, is triggered in the UE, the C-DNS is selected as the DNS server for the DNS Query based on the received DNS information.

In step 511, a local UPF insertion to access local DN is triggered.

In step 512, a PDU session modification procedure is performed to update the DNS information for the PDU session. If the 5GC (e.g. SMF) makes decision for adding or updating L-DNS server for DNS handling for the DNS message for some (or all) local applications, the DNS information for the PDU session is updated with the information of the L-DNS server via the PDU session modification procedure. This may be done via DHCP message or RA message via user plane.

In steps 513a, DNS Query for local application, supposed to be resolved in L-DNS server, is triggered in the UE. In step 513b, the related L-DNS server is selected as the DNS server for the DNS Query based on the received DNS information. The address of L-DNS server is used as the DA for the DNS query message. In step 513c, DNS query is sent to the L-DNS server for resolution. In step 513d, the DNS response is received from the L-DNS server.

In all of the first to the third embodiments, LDNSR, C-DNS server and L-DNS server can be configured as the DNS server for applications. Accordingly, the LDNSR, the C-DNS server or the L-DNS server can be used as the DA for the DNS query message.

In the above description of the first to the third embodiment, L-DNS server can be included in the DNS server list, configured as the DNS server for applications, used as the DA for the DNS query message. The L-DNS server can be used in conjunction with an L-DNS resolver. That is, when the L-DNS resolver is deployed, when L-DNS server is included in the DNS server list, i.e. can be configured as the DNS server for local applications, the L-DNS resolver can be used as the DA for the DNS query message, while the L-DNS resolver forwards the DNS query message to the L-DNS server to resolute.

An application can have one or more deployments. For example, the application can be deployed centrally. In addition, the application can be also deployed in one or more edge platforms. For each deployment, the application may have a different preferred DNS server. In addition, one or more applications can be accessed in one PDU session. For example, if two applications are accessed in one PDU session, each of the two applications has a different preferred DNS server (e.g. due to different conditions, such as different deployments) . Accordingly, according to the first to the third embodiments, the DNS information can identify and configure one or more DNS servers. For example, the DNS information may include a list of DNS servers for at least one application, wherein each application has one or more DNS servers (e.g. C-DNS server, LDNSR, L-DNS server, L-DNS resolver, etc) in different conditions. For example, for the application deployed centrally, the DNS query for the application can be sent to the C-DNS server or the LDNSR; for the application deployed locally in an edge platform, the DNS query can be sent to the L-DNS server or the L-DNS resolver or the LDNSR. Note that the application can be deployed locally in one or more edge platforms. When the application is deployed locally in one edge platform (e.g. edge platform1) , the DNS query can be sent to the L-DNS server or the L-DNS resolver (e.g. L-DNS server1 or L-DNS resolver1) that is local to the one edge platform (e.g. edge platform1) or the LDNSR (that can forward the DNS query to the L-DNS server; note that the LDNSR can be deployed centrally, or it may be deployed locally) . When the application is deployed locally in another edge platform (e.g. edge platform2) , the DNS query can be sent to the L-DNS server or the L-DNS resolver (e.g. L-DNS server2 or L-DNS resolver2) that is local to the other edge platform (e.g. edge platform2) , or the LDNSR (that can forward the DNS query to the L-DNS server) . For another example, when two applications are accessed in one PDU session, the DNS server to which the DNS query for one of the two applications is sent and the DNS server to which the DNS query for the other of the two applications is sent can be included in one DNS information. Note that it is not necessary that the DNS server for each deployment of each application is separately configured. For example, all applications (or a group of applications) in one deployment (e.g. in one edge platform (e.g. edge platform1) ) may be configured with the same DNS server (e.g. L-DNS server1 or L-DNS resolver1 or LDNSR) .

Figure 6 is a schematic flow chart diagram illustrating an embodiment of a method 600 according to the present application. In some embodiments, the method 600 is performed by a remote unit, such as a UE. In certain embodiments, the method 600 may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

The method 600 may include 602 receiving DNS information for the UE or for a PDU session, wherein the DNS information identifies and configures one or more DNS servers for at least one application; and 604 selecting a DNS server for DNS resolution for the at least one application based on the received DNS information. For example, when a DNS query for the application deployed centrally is triggered, the DNS query is sent to a C-DNS server or LDNSR; and when a DNS query for the application deployed locally is triggered, the DNS query is sent to an L-DNS server or an L-DNS resolver or the LDNSR.

Preferably, the DNS information further includes validation criteria for the one or more DNS servers. Still preferably, the DNS information further includes precedence for the one or more DNS servers. The method may further comprise transmitting an indication of UE support for DNS selection policy in UE registration procedure and/or in PDU session establishment procedure. During the PDU session establishment procedure or due to insertion of a local UPF, the method may further comprise receiving updated DNS information. The DNS information can be received as a part of URSP rule or as a separate rule.

Figure 7 is a schematic flow chart diagram illustrating an embodiment of a method 700 according to the present application. In some embodiments, the method 700 is performed by a network function, such as PCF. In certain embodiments, the method 700 may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

The method 700 may include 702 constructing DNS information for a UE or for a PDU session, wherein the DNS information identifies and configures one or more DNS servers; and 704 transmitting the DNS information.

Preferably, the DNS information further includes validation criteria for the one or more DNS servers. Still preferably, the DNS information further includes precedence for the one or more DNS servers. The DNS information may be constructed based on DNS information configured locally or dynamically from AF. The method may further comprise receiving an indication of UE support for DNS selection policy in UE registration procedure and/or in PDU session establishment procedure. During the PDU session establishment procedure or due to insertion of a local UPF, the method may further comprise constructing updated DNS information based on additional DNS information, and transmitting the updated DNS information. The DNS information can be transmitted as a part of URSP rule or as a separate rule.

Figure 8 is a schematic flow chart diagram illustrating an embodiment of a method 800 according to the present application. In some embodiments, the method 800 is performed by a network function, such as SMF. In certain embodiments, the method 800 may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

The method 800 may include 802 constructing DNS information for PDU session based on at least one of DNS information configured locally, DNS information decided locally and DNS information received from PCF, wherein the DNS information for PDU session identifies and configures one or more DNS servers; and 804 transmitting the DNS information for PDU session.

The DNS information decided locally can be LDNSR information.

Figure 9 is a schematic block diagram illustrating apparatuses according to one embodiment.

Referring to Figure 9, the UE includes a processor, a memory, and a transceiver. The processor implements a function, a process, and/or a method which are proposed in Figure 6.

The UE comprises a processor; and a receiver coupled to the processor, the receiver being configured to receive DNS information for the UE or for a PDU session, wherein the DNS information identifies and configures one or more DNS servers for at least one application, wherein the processor is configured to select a DNS server for DNS resolution for the at least one application based on the received DNS information. For example, when a DNS query for the application deployed centrally is triggered, the DNS query is sent to a C-DNS server or LDNSR; and when a DNS query for the application deployed locally is triggered, the DNS query is sent to an L-DNS server or an L-DNS resolver or the LDNSR.

Preferably, the DNS information further includes validation criteria for the one or more DNS servers. Still preferably, the DNS information further includes precedence for the one or more DNS servers. The UE may further comprise a transmitter that transmits an indication of UE support for DNS selection policy in UE registration procedure and/or in PDU session establishment procedure. During the PDU session establishment procedure or due to insertion of a local UPF, the receiver may further receive updated DNS information. The DNS information can be received as a part of URSP rule or as a separate rule.

Figure 10 is a schematic block diagram illustrating apparatuses according to one embodiment.

The network function (e.g. PCF or SMF) includes a processor, a memory, and a transceiver. The processor implements a function, a process, and/or a method which are proposed in Figure 7 or 8.

The network node PCF comprises: a processor configured to construct DNS information for a UE or for a PDU session, wherein the DNS information identifies and configures one or more DNS servers; and a transmitter coupled to the processor, the transmitter being configured to transmit the DNS information.

Preferably, the DNS information further includes validation criteria for the one or more DNS servers. Still preferably, the DNS information further includes precedence for the one or more DNS servers. The DNS information may be constructed based on DNS information configured locally or dynamically from AF. The PCF may further comprise a receiver that receives an indication of UE support for DNS selection policy in UE registration procedure and/or in PDU session establishment procedure. During the PDU session establishment procedure or due to insertion of a local UPF, the processor may further construct updated DNS information based on additional DNS information, and the transmitter transmits the updated DNS information. The DNS information can be transmitted as a part of URSP rule or as a separate rule.

The network node SMF comprises: a processor configured to construct DNS information for PDU session based on at least one of DNS information configured locally, DNS information decided locally and DNS information received from PCF, wherein the DNS information for PDU session identifies and configures one or more DNS servers; and a transmitter coupled to the processor, the transmitter being configured to transmit the DNS information for the PDU session. The DNS information decided locally can be LDNSR information.

Layers of a radio interface protocol may be implemented by the processors. The memories are connected with the processors to store various pieces of information for driving the processors. The transceivers are connected with the processors to transmit and/or receive message or information. Needless to say, the transceiver may be implemented as a transmitter to transmit the information and a receiver to receive the information.

The memories may be positioned inside or outside the processors and connected with the processors by various well-known means.

In the embodiments described above, the components and the features of the embodiments are combined in a predetermined form. Each component or feature should be considered as an option unless otherwise expressly stated. Each component or feature may be implemented not to be associated with other components or features. Further, the embodiment may be configured by associating some components and/or features. The order of the operations described in the embodiments may be changed. Some components or features of any embodiment may be included in another embodiment or replaced with the component and the feature corresponding to another embodiment. It is apparent that the claims that are not expressly cited in the claims are combined to form an embodiment or be included in a new claim.

The embodiments may be implemented by hardware, firmware, software, or combinations thereof. In the case of implementation by hardware, according to hardware implementation, the exemplary embodiment described herein may be implemented by using one or more application-specific integrated circuits (ASICs) , digital signal processors (DSPs) , digital signal processing devices (DSPDs) , programmable logic devices (PLDs) , field programmable gate arrays (FPGAs) , processors, controllers, micro-controllers, microprocessors, and the like.

Embodiments may be practiced in other specific forms. The described embodiments are to be considered in all respects to be only illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

A method performed at a UE, comprising:

receiving DNS information for the UE or for a PDU session, wherein the DNS information identifies and configures one or more DNS servers for at least one application; and

selecting a DNS server for DNS resolution for the at least one application based on the received DNS information.
The method of claim 1, wherein, the DNS information further includes validation criteria for the one or more DNS servers.
The method of claim 1, wherein, the DNS information further includes precedence for the one or more DNS servers.
The method of claim 1, further comprising: transmitting an indication of UE support for DNS selection policy in UE registration procedure and/or in PDU session establishment procedure.
The method of claim 1, wherein, receiving the DNS information comprising: receiving the DNS information as a part of URSP rule or as a separate rule.
The method of claim 4, further comprising: during the PDU session establishment procedure or due to insertion of a local UPF, receiving updated DNS information.
The method of claim 1, wherein, when a DNS query for the application deployed centrally is triggered, the DNS query is sent to a C-DNS server or LDNSR; and when a DNS query for the application deployed locally is triggered, the DNS query is sent to an L-DNS server or an L-DNS resolver or the LDNSR.
A method performed at a PCF, comprising:

constructing DNS information for a UE or for a PDU session, wherein the DNS information identifies and configures one or more DNS servers; and

transmitting the DNS information.
The method of claim 8, further comprising: during PDU session establishment and/or due to local UPF insertion, constructing updated DNS information based on additional DNS information, and transmitting the updated DNS information.
The method of claim 8, wherein, constructing the DNS information comprising: constructing the DNS information based on DNS information configured locally or dynamically from AF.
A method performed at a SMF, comprising:

constructing DNS information for PDU session based on at least one of DNS information configured locally, DNS information decided locally and DNS information received from PCF, wherein the DNS information for PDU session identifies an configures one or more DNS servers; and

transmitting the DNS information for PDU session.
The method of claim 11, wherein, the DNS information decided locally comprising LDNSR information.
A UE, comprising:

a processor; and

a receiver coupled to the processor, the receiver being configured to receive DNS information for the UE or for a PDU session, wherein the DNS information identifies and configures one or more DNS servers for at least one application,

wherein the processor is configured to select a DNS server for DNS resolution for the at least one application based on the received DNS information.
A network node, comprising:

a processor configured to construct DNS information for a UE or for a PDU session, wherein the DNS information identifies and configures one or more DNS servers; and

a transmitter coupled to the processor, the transmitter being configured to transmit the DNS information.
A network node, comprising:

a processor configured to construct DNS information for PDU session based on at least one of DNS information configured locally, DNS information decided locally and DNS information received from PCF, wherein the DNS information for PDU session identifies and configures one or more DNS servers; and

a transmitter coupled to the processor, the transmitter being configured to transmit the DNS information for the PDU session.