7 Network Function Services and Descriptions
23.5483GPP5G System Enhancements for Edge ComputingRelease 17Stage 2TS
7.1 EASDF Services
7.1.1 General
The following table illustrates the EASDF Services and Service Operations.
Table 7.1.1-1: NF services provided by the EASDF
|
Service Name |
Service Operations |
Operation Semantics |
Example Consumer(s) |
|
Neasdf_DNSContext |
Create |
Request/Response |
SMF |
|
Update |
Request/Response |
SMF |
|
|
Delete |
Request/Response |
SMF |
|
|
Notify |
Subscribe/Notify |
SMF |
|
|
Neasdf_BaselineDNSPattern |
Create |
Request/Response |
SMF |
|
Update |
Request/Response |
SMF |
|
|
Delete |
Request/Response |
SMF |
7.1.2 Neasdf_DNSContext Service
7.1.2.1 General
Service description: This service enables the consumer to create, update, or delete DNS context in EASDF and to Subscribe to DNS message related reporting from EASDF.
DNS contexts in EASDF include rules on how EASDF is to handle DNS messages.
7.1.2.2 Neasdf_DNSContext_Create Service Operation
Service operation name: Neasdf_DNSContext_Create
Description: Create a DNS context in EASDF.
Input, Required: UE IP address, DNN, S-NSSAI, Notification Endpoint.
Input, Optional: DNS message handling rules.
DNS message detection and Actions(s) are specified in clause 6.2.3.2.2.
Output, Required: If successful, IP address of the EASDF, EASDF Context ID, Result Indication.
Output, Optional: None.
7.1.2.3 Neasdf_DNSContext_Update Service Operation
Service operation name: Neasdf_DNSContext_Update
Description: Update the DNS context in EASDF, or indicate EASDF to forward the DNS Response to UE.
Input, Required: EASDF Context ID, updated DNS message handling rules.
Input, Optional: None.
Output, Required: Result Indication.
Output, Optional: None.
7.1.2.4 Neasdf_DNSContext_Delete Service Operation
Service operation name: Neasdf_DNSContext_Delete
Description: Delete the DNS context in EASDF.
Input, Required: EASDF Context ID.
Input, Optional: None.
Output, Required: Result Indication.
Output, Optional: None.
7.1.2.5 Neasdf_DNSContext_Notify Service Operation
Service operation name: Neasdf_DNSContext_Notify
Description: EASDF reports DNS message related information to the consumer when receiving DNS Query or DNS Response.
Input, Required: DNS message reporting information (DNS message content specified in clause 6.2.3.2.2 and corresponding DNS message type), Notification Endpoint.
Input, Optional: DNS message identifier.
Output, Required: Result Indication.
Output, Optional: None.
7.1.3 Neasdf_BaselineDNSPattern Service
7.1.3.1 General
This service provides the capability to create, update or remove BaselineDNSPattern in EASDF. See clause 6.2.3.4.4 for detailed procedure.
7.1.3.2 Neasdf_BaselineDNSPattern_Create Service Operation
Service operation name: Neasdf_BaselineDNSPattern_Create
Description: Create the BaselineDNSPattern in EASDF.
Input, Required: BaselineDNSPattern.
Input, Optional: None.
Output, Required: Success or Failure.
Output, Optional:
7.1.3.3 Neasdf_BaselineDNSPattern_Update Service Operation
Service operation name: Neasdf_BaselineDNSPattern_Update
Description: Update the BaselineDNSPattern in EASDF.
Input, Required: Updated BaselineDNSPattern.
Input, Optional: None.
Output, Required: Success or Failure.
Output, Optional: None.
7.1.3.4 Neasdf_BaselineDNSPattern_Delete Service Operation
Service operation name: Neasdf_BaselineDNSPattern_Delete
Description: Delete the BaselineDNSPattern in EASDF.
Input, Required: Baseline DNS message detection template ID and/or Baseline DNS handling actions ID.
Input, Optional: None.
Output, Required: Result.
Output, Optional: None.
Annex A (Informative):
EAS Discovery Using 3rd Party Mechanisms
There are different IP discovery mechanisms existing in the application layer. For example, the application client can generate the DNS Query outside of DNS libraries in the OS with DoT, DoH or other over the top mechanisms.
The third party can also deploy a service scheduling server to determine the (E)AS IP address based on the UE’s HTTP(S) request. In this case, the DNS firstly resolves the FQDN in the DNS Query of the UE into the IP address of the service scheduling server and then the UE contacts the service scheduling server that can provide the IP address of the EAS that the UE is then to contact.
For the Distributed Anchor Point connectivity model, in order to enable EAS discovery by third party mechanisms, the DNS Server or service scheduling server in the third party could be pre-configured with mapping information between the IP address range which can correspond to the Central PSA UPF or other entities (e.g. a NAT server) on the N6 interface and EAS information. In this case, the DNS Server or service scheduling server in the third party can take the source IP address of the UE request as the location information of UE. The DNS and/or service scheduling server pre-configuration can be based on the agreement between the MNO and service provider.
For the Session Breakout connectivity model, based on agreement with the operator, a possible solution for the service scheduling server is as follows:
– The IP address of the service scheduling server can be set as a condition in the ULCL UPF to offload traffic. The IP address of service scheduling server can be pre-configured or resolved by the EASDF based on procedure defined in clause 6.2.2.2.
– NAT server can be deployed in the L- DN or local N6 interface, in order that the source IP address of the UE request sent to the service scheduling server can correspond to the UE location related information.
NOTE: Otherwise, the source IP address of the UE request message sent to the third party DNS server / service scheduling server is bound with the central PSA UPF, so it’s impossible for the third party DNS server / service scheduling server to know which local EAS address could be allocated to the UE.
Based on the mapping relationship between the IP ranges of UE request and the EAS information, the EAS IP address can be allocated to the UE. The above example is briefly shown in Figure A-1.
Figure A-1: Service scheduling server mechanism for Session Breakout connectivity model
Annex B (Informative):
Application Layer based EAS (Re-)Direction
During the application relocation, the AF can reselect a new EAS for the UE. Reselection can be triggered by the AF when it receives a UP path change notification or by an internal trigger of the AF (e.g. load balancing, UE location change, etc.). When the new EAS is reselected, the UE is provided the new EAS address via application layer signalling. For example, the UE can receive the URL or FQDN of the new EAS once the application context relocation is complete and then use DNS to resolve the URL or FQDN. The UE can also obtain the new EAS address via HTTP redirection.
NOTE: The Application layer signalling between the AF (or Old EAS) and UE is application specific and is outside the scope of this specification.
Annex C (Informative):
Considerations for EAS (re)Discovery