CN117997827A

CN117997827A - Enhancement of edge network access for UEs

Info

Publication number: CN117997827A
Application number: CN202410200861.8A
Authority: CN
Inventors: 帕斯卡尔·爱德杰卡普; J·宁勒库; M·斯达斯尼克; Q·李; 李鸿堃; C·姆拉丁; 张国栋
Original assignee: InterDigital Patent Holdings Inc
Current assignee: InterDigital Patent Holdings Inc
Priority date: 2021-02-12
Filing date: 2022-02-11
Publication date: 2024-05-07
Also published as: CN116982303A

Abstract

The present disclosure relates to enhancement of edge network access for UEs. Methods, apparatus, and systems for improved edge network access for UEs are described. According to some aspects, a UE may receive a first Data Network Name (DNN) from an application and determine that the first DNN is associated with a second Data Network Name (DNN) based on a Data Network Name (DNN) replacement rule, wherein the first DNN and the second DNN are different. The UE may determine to associate traffic from the application with a Protocol Data Unit (PDU) session based on the DNN substitution rule, wherein the PDU session may be used to send data from the application to a network and the PDU session is associated with the second DNN.

Description

Enhancement of edge network access for UEs

The application is a divisional application of PCT application entering China national stage, wherein the international application date is 2022, 02, 11 and the national application number is 202280018863.4, and the application name is 'enhancement of edge network access for UE'.

Cross Reference to Related Applications

The present application claims the benefit of U.S. provisional application No. 63/148,842 entitled "enhancement of edge network access for UEs (ENHANCEMENTS FOR EDGE NETWORK ACCESS FOR A UE)" filed on month 2 of 2021 and U.S. provisional application No. 63/230,095 entitled "enhancement of edge network access for UEs" filed on month 8 of 2021, the contents of which are hereby incorporated by reference in their entirety.

Background

Edge computation is designed to support services with low latency. For example, TS23.503, release 16, states that there is no requirement to check again the location criteria of the User Equipment (UE) routing policy (URSP) rules during the lifetime of a Protocol Data Unit (PDU) session. However, the use case of supporting low latency services with mobility is the basis of 5G cellular networks, where changes in location are common. Thus, this also means that when the UE has an established PDU session and if the UE is mobile, the UE may span a location where URSP rules may not be valid.

URSP time window and location criteria are designed with consideration for background data transmissions. However, for edge computing applications, it may be desirable to extend and utilize the range of time windows and location criteria in URSP rules. It should be noted that the current specifications do not require the UE to check time windows and location criteria during the lifetime of the PDU session. However, if URSP rules are configured with location criteria in order to serve the UE towards the edge (e.g., local), and if the UE does not periodically check whether the UE location matches the location criteria associated with the route, the UE will not detect when the route is no longer suitable.

The UE receives URSP the rule after successful registration, which the UE uses during PDU session establishment to select the appropriate route. When the UE is mobile and in a certain location, the DNN provided by the URSP rule may not be available or accessible. In addition, known DNNs may not be able to deliver application service requirements (e.g., qoS, SLA) due to traffic, service availability, or other limitations.

When a UE is in the process of being relocated from one Edge Application Server (EAS) to another, the core network may need to buffer UL packets from the UE in the PSA UPF until the EAS relocation is complete. However, the core network (SMF) may not know how long data from the UE/AC needs to be buffered in the PSA. Furthermore, the SMF may not be able to accurately know the buffer space or buffer time required for seamless EAS relocation, as the requirements may vary for each application. If application requirement information for seamless EAS relocation is necessary, it is desirable to define application requirement information, methods of transmitting such information to the core network, and how such information affects the EAS relocation process.

The UE may have connected to an application server in an edge network and has cached the relevant DNS record locally. But applications located at the old edge network may not be suitable for UE access when the UE moves. When the UE attempts to update the DNS cache, it may fully flush the cache, which may be undesirable for future DNS cache references.

Edge network access for UE deployment may cover a wide variety of scenarios, servers, gateways, and devices, such as those described, for example, in the following: 3GPP TS23.503 policy and charging control framework for 5G systems, stage 2 (16 th edition); 3GPP TS23.501 System architecture for 5G System (5 GS), stage 2 (16 th edition); 3GPP TS23.502 procedure for 5G System (5 GS), phase 2 (16 th edition); and 3GPP TS 24.526 User Equipment (UE) policies for 5G systems (5 GS), phase 3 (release 17).

Disclosure of Invention

Methods, apparatus, and systems for improved edge network access for UEs are described herein that address the above-described shortcomings.

According to some aspects, an apparatus may include a UE. The apparatus may include a processor, communication circuitry, and memory. The memory may store instructions that, when executed by the processor, cause the apparatus to perform one or more operations.

The UE may receive a first Data Network Name (DNN) from an application. The UE may determine that the first DNN is associated with a second DNN based on a DNN replacement rule. For example, the first DNN and the second DNN may be different. Further, the DNN substitution rule may be received by the UE in a UE configuration update message.

According to some aspects, the UE may determine to associate traffic from the application with a PDU session (e.g., associated with the second DNN) based on the DNN substitution rules. The PDU session may be used (e.g., by the UE) to send data from the application to the network. Receiving the first DNN from the application may also cause the UE to send a PDU session establishment request to the network, for example. The PDU session establishment request may include the second DNN. For example, the PDU session establishment request may include an indication that the second DNN is a replacement DNN.

According to some aspects, the UE may send an indication to the network that the UE is able to receive the DNN replacement rule (e.g., in a registration request). The DNN replacement rules may be part of a user equipment routing policy (URSP) rule. The USRP rule may include a routing descriptor (RSD). The USRP rules may be received from the network in a non-access stratum (NAS) message. According to some aspects, the URSP rule may be initiated in a Policy Control Function (PCF) and the NAS message may be received from an access and mobility management function (AMF).

According to some aspects, the UE may determine that the first DNN is part of the traffic descriptor of the URSP rule, and may determine that the second DNN is part of the RSD. For example, determining that the first DNN is part of the traffic descriptor of the URSP rule and determining that the second DNN is part of the RSD may indicate that the DNN replacement rule is part of the URSP rule and/or that the first DNN should be replaced with the second DNN.

According to some aspects, the first network function may receive a DNN substitution rule associated with the UE from the second network function. According to some aspects, the DNN substitution rule may be part of the URSP rule. For example, DNN substitution rules may be included in a message, and the message may include a plurality URSP of rules. The first URSP rule including the DNN replacement rule may have a higher priority than the second URSP rule that does not include the DNN replacement rule.

Further, the first network function may be an AMF and the second network function may be a PCF. For example, when the AMF invokes Npcf _ UEPolicyControl _create service, the PCF may send the DNN replacement rule to the AMF. The first network function may send a NAS message to the second network function. The NAS message may include the DNN substitution rule. According to some aspects, during the lifetime of a PDU session, it may be necessary to re-evaluate URSP the rules to check if the routing verification criteria are valid. Therefore, URSP rules may be enhanced.

In one aspect, a mechanism is provided by which the network may indicate to the UE in the URSP rule that the routing verification criteria need to be checked (e.g., re-evaluated) each time the UE switches to a new cell, selects a new cell, or performs a registration area update.

In one aspect, the mechanism of the location criteria is re-evaluated when URSP is re-evaluated in a timely manner, e.g., when the UE moves from EPC to 5 GC.

In an aspect, the URSP rule may include a timer value that may be used by the UE to determine how often the route should be checked (e.g., re-evaluated), e.g., every 1 minute.

In one aspect, a URSP regular routing descriptor (RSD) may include a time window re-evaluation indication (TWRI) flag whose presence indicates to the UE that time window information in the RSD should not only be used as a validation criterion when a PDU session is established, but also to determine when the PDU session should be modified or terminated.

In one aspect, the RSD of the URSP rule may include a location criteria re-assessment indication (LCRI) flag, the presence of which indicates to the UE that the location criteria information in the RSD should not only be used as a validation criterion when a PDU session is established, but also to determine when the PDU session should be modified or terminated.

In one aspect, the network may provide location offset allowance (LDA) in the RSD to the UE when the RSD includes location criteria. For example, the LDA may indicate to the UE how much the UE's location may deviate from the location criteria after the PDU session is established.

In one aspect, the URSP reevaluation including location criteria may be initiated by the UE application based on dropped packets or delay threshold triggers as a response from the edge network or from the UE protocol stack.

In one aspect, when the EAS is relocated, the UE may re-evaluate the URSP rules including the location criteria for application of a stream.

In one aspect, for an ongoing application flow, the UE may re-evaluate the URSP rule with location criteria to determine if a better route can be selected when the DNS record for EAS is updated or refreshed in the UE.

According to some embodiments, 5GC may be enhanced such that when certain conditions are met, the UE may be able to select and replace DNNs in the URSP rules, e.g., so that application traffic may use it to reach the required services. Thus, enhancements may be made to application-triggered DNN replacement.

In one aspect, the UE may be configured with DNN replacement rules (e.g., that inform the UE to grant or need it under certain conditions) to replace the first DNN provided by the application with the second DNN.

In one aspect, the UE may indicate to the network that it is capable of receiving DNN replacement rules during a UE registration or UE registration update procedure.

In one aspect, the UE may receive DNN replacement rules (e.g., originating from AMF, PCF, and/or UDM/UDR) from the network via NAS messaging.

According to some embodiments, the UE may be able to assist the network by providing application requirements to the network to assist the network in selecting an appropriate EAS to serve the UE. Thus, enhancements may be made to enable 5GC to have this capability.

In one aspect, to mitigate uplink packet loss for a UE while facilitating seamless EAS relocation, application Requirement Information (ARI) for applications in the UE is introduced.

In one aspect, the UE may use a PDU session establishment procedure to transmit an ARI to the network (SMF).

In one aspect, the ARI sent by the UE may be used by the SMF to effect a change in UL CL and introduce buffer metrics (e.g., buffer time, buffer capacity) into the PSA UPF for an ongoing PDU session during EAS relocation.

According to some embodiments, the AF impact may also be used to inform the network of metrics required during EAS relocation.

In one aspect, EAS may provide (e.g., via NEF) parameters in a suggested ARI format for CN (SMF) relocation for seamless applications.

In one aspect, a core network (SMF) may utilize a DNN replacement mechanism to send EAS relocation information (e.g., based on an AF traffic impact request including application requirement information) to the AMF and the UE.

According to some embodiments, the UE may be required to flush its DNS cache during the EAS relocation procedure.

In one aspect, during the EAS discovery process, the associated impact field sent with the DNS re-resolve indication via the PDU session modification command may enable the UE to replace or remove DNS records based on a predefined algorithm. For example, the algorithm may identify network information received in an associated impact field and may selectively replace/remove DNS records. This may enable the UE to reduce its DNS resolution time in the future.

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to features that solve any or all disadvantages noted in any part of this disclosure.

Drawings

A more detailed understanding of the description may be had by way of example only, given below in connection with the accompanying drawings.

Fig. 1 shows an example of a UE changing location and its service edge network;

fig. 2 shows an example of a UE application transmitting application requirement information during a PDU session establishment procedure;

FIG. 3 illustrates an example of storing SMFs and transferring ARIs for each application to a PSA UPF;

Fig. 4 shows an example of handling an AF request, e.g. based on 3gpp ts23.502 clause 4.3.6.2;

fig. 5 shows an example of session continuity for SSC pattern 3 based on TS23.502 clause 4.3.5.2, for example;

Fig. 6 shows an example of selective DNS cache flushing in a UE;

Fig. 7 shows an example of a UE depicting enhancements URSP, ARI and DNS cache for each application;

fig. 8 illustrates an exemplary procedure for supporting receipt and application of DNN replacement rules.

Fig. 9A illustrates an exemplary communication system.

Fig. 9B, 9C, and 9D are system diagrams of an exemplary RAN and core network.

Fig. 9E illustrates another exemplary communication system.

Fig. 9F is a block diagram of an exemplary apparatus or device, such as a WTRU.

FIG. 9G is a block diagram of an exemplary computing system.

Detailed Description

Table 0.1 describes some abbreviations used herein.

TABLE 0.1 abbreviation

AC	Application client
		AF	Application function
AMF	Access management function
		APN	Access point name
ARI	Application requirement information
		AS	Application server
CN	Core network
		DNAI	Data network access identifier
DNN	Data network name
		DNS	Domain name server
EAS	Edge application server
		EDN	Edge data network
FQDN	Fully qualified domain name
		GUI	Graphic user interface
LADN	Local area data network
		NEF	Network opening function
NF	Network function
		NRF	Network resource function
PDU	Protocol data unit
		PSA	PDU session anchor
RA	Registration area
		SMF	Session management function
S-NSSAI	Single network slice selection assistance information
		TA	Tracking areas
UDM	Unified data management
		UE	User equipment
UL	Uplink channel
		UL CL	Uplink classifier
UP	User plane
		UPF	User plane functionality
V2X	Vehicle-mounted everything

Table 0.2 describes some definitions of selected terms used herein.

TABLE 0.2 definition

DNN and PDU session management

Data network name

The DNN in 5GS is equivalent to the APN in LTE. See TS23.503 policy and charging control framework for 5G systems; stage 2 (16 th edition). The two identifiers have equal meaning between their respective systems and carry similar information. DNNs can be used, for example: (1) selecting SMF and UPF for PDU session; (2) selecting an N6 interface for the PDU session; and (3) determining a policy to apply to the PDU session. According to an aspect, wild card DNN is a value of a DNN field of a subscription DNN list that may be used for session management subscription data defined in clause 5.2.3.3 of TS 23.502. For example, wild card DNN may be used with an operator' S S-NSSAI to allow subscribers to access any data network supported within the network slice associated with S-NSSAI.

Session management

The 5GC supports PDU connectivity services. The PDU connection service is supported via a PDU session established based on a request from the UE. The subscription information for each S-NSSAI may contain a list of subscribed DNNs and a default DNN. When the UE does not provide DNN in the NAS message containing the PDU session establishment request for a given S-NSSAI, if the default DNN is present in the subscription information of the UE, the serving AMF determines the DNN for the requested PDU session by selecting the default DNN for that S-NSSAI; otherwise, the service AMF selects a locally configured DNN for the S-NSSAI.

According to an aspect, using the procedure defined in TS23.502 clause 4.16.12.2, URSP in the UE is always up-to-date and thus the DNN requested by the UE will be up-to-date. To cover the case where the UE operates using a local configuration, as well as other cases where an operator policy may be used to replace the "latest" UE-requested DNN with another DNN that is only used internally in the network, the PCF may indicate to the AMF, during the UE registration procedure, the operator policy used at PDU session establishment for DNN replacement of the UE-requested DNN. The PCF may indicate a policy for DNN replacement of DNNs requested by UEs not supported by the network, and/or a list of DNNs requested by UEs for each S-NSSAI valid for the serving network as an object of replacement (details are described in TS 23.503).

If the DNN provided by the UE is not supported by the network and the AMF cannot select the SMF by querying the NRF, the AMF may reject the NAS message from the UE containing the PDU session establishment request for reasons indicating that the DNN is not supported unless the PCF provides a policy to perform DNN replacement of the unsupported DNN.

If the DNN requested by the UE is indicated for replacement or the DNN provided by the UE is not supported by the network and the PCF provides a policy to perform DNN replacement for the DNN requested by the UE that is not supported by the network, the AMF may interact with the PCF to perform DNN replacement. During the PDU session establishment procedure and as a result of DNN replacement, the PCF may provide a list of selected DNNs for replacement, which is applicable to the S-NSSAI requested by the UE at PDU session establishment. The AMF may use the selected DNN in a query to the NRF for SMF selection and provide the requested and selected DNN to the selected SMF.

According to an aspect, interaction between the AMF and the PCF may be required when performing DNN replacement in the network.

URSP rule

The UE routing policy (URSP) includes a prioritized list of URSP rules. See 3gpp TS 23.503. Table 1 depicts URSP.

TABLE 1 UE routing strategy

The structure of URSP rule is described in tables 2 and 3.

Table 2-UE routing policy rules

Table 3-routing descriptor

URSP rule evaluation

For each new application flow that needs to be established, the UE evaluates URSP the rules in order of rule priority, and then triggers the PDU session to be established or to use the existing PDU session for that flow. The location attribute is a URSP rule constraint that needs to be valid for URSP rules to apply. That is, when the routing descriptor includes a time window or location criteria, traffic flows are considered to match only when the location of the UE matches the location criteria validity condition. In addition, TS23.503, release 16, describes that when certain conditions are met, the UE evaluates (e.g., re-evaluates) the validity of URSP rules in a timely manner, e.g., updated URSP by the PCF when: UE moves from EPC to 5GC; allowed NSSAI or a change in configuration NSSAI; LADN DNN changes in availability; the UE is registered on 3GPP or non-3 GPP access; the UE establishes a connection with the WLAN access.

According to TS24.526, the UE may re-evaluate URSP rules to check if a change in the association of an application with a PDU session is required when: the UE performs periodic URSP rule reevaluations based on the UE implementation; the UE NAS layer indicates that an existing PDU session for routing traffic of the application based on URSP rules is released; URSP is updated by the PCF; the UE NAS layer instructs the UE to perform an intersystem change from S1 mode to N1 mode; the UE NAS layer indicates that the UE is successfully registered on 3GPP access or non-3 GPP access in an N1 mode; the UE establishes or releases a connection with the WLAN access and transmission of PDUs via the non-3 GPP access application outside the PDU session becomes available/unavailable; allowed NSSAI is changed; or LADN information is changed.

If the reevaluation results in a change in the association of the application with the PDU session, the UE may implement such a change immediately or when the UE returns to the 5GMM-IDLE mode. After re-evaluation, URSP processing layer may request the UE NAS layer to release the existing PDU session.

Statement of problem

Benefits of deploying Edge Application Servers (EAS) at the edge network of the 3GPP system may include reduced access delay and increased reliability of Application Clients (ACs) in UEs accessing services provided by these EAS. Fig. 1 depicts an Autonomous Vehicle (AV) AV1 moving from a location a to a location B, where location a and location B represent units such as cells or tracking areas. The autonomous vehicle may host a UE, where the UE may have V2X AC capability. Systems such as V2X require (ultra) low latency services. The UE communicates with V2X services (e.g., a queuing driving service, a collaborative driving service, a collision avoidance service, etc.) deployed on edge nodes in the 3GPP system. The preferred method for V2XAC access to V2X services would be via V2X EAS deployed in an edge network in a system closer to the vehicle.

When this AV travels from one location to another, the V2X AC can switch between EAS hosted on the nearest different edge network, and such switching must be properly coordinated. Fig. 1 shows AV1 moving from location a to location B served by EAS1, eventually served by EAS2 for the same service.

Problem(s)

Edge computation is designed to support services with low latency. TS23.503, 16 th edition, states that it is not required to check URSP the regular location criteria again during the lifetime of a PDU session. However, use cases supporting low latency services with mobility, such as the case discussed herein (see fig. 1), are fundamental to 5G cellular networks, where changes in location are common. This also means that when the UE has an established PDU session and if the UE is mobile, the UE may cross a location where URSP rules may not be valid.

URSP time window and location criteria may be designed taking into account background data transmissions. However, for edge computing applications, it may be desirable to extend and utilize the range of time windows and location criteria in URSP rules. It should be noted that the current specifications do not require the UE to check time windows and location criteria during the lifetime of the PDU session. See 3gpp TS 23.503 policy and charging control framework for 5G systems; stage 2 (16 th edition). However, if URSP rules are configured with location criteria in order to serve the UE towards the edge (e.g., local), and if the UE does not periodically check whether the UE location matches the location criteria associated with the route, the UE will not detect when the route is no longer suitable.

The UE may receive URSP a rule after successful registration, which the UE may use during PDU session establishment to select the appropriate route. When the UE is mobile and in a certain location, the DNN provided by the URSP rule may not be available or accessible. In addition, known DNNs may not be able to deliver application service requirements (e.g., qoS, SLA) due to traffic, service availability, or other limitations.

When the UE is in the process of relocation from one EAS to another, the core network may need to buffer UL packets from the UE in the PSA UPF until the EAS relocation is complete. However, the core network (SMF) may not know how long data from the UE/AC needs to be buffered in the PSA. Furthermore, the SMF may not be able to accurately know the buffer space or buffer time required for seamless EAS relocation, as the requirements may vary for each application. If application requirement information for seamless EAS relocation is necessary, it is desirable to define application requirement information, methods of transmitting such information to the core network, and how such information affects the EAS relocation process.

Summary

During the lifetime of the PDU session, it may be necessary to re-evaluate URSP the rules to check if the routing verification criteria are valid. The following enhancements in URSP rules may be made according to some aspects.

First, a mechanism by which the network may indicate to the UE in the URSP rule that the routing verification criteria need to be checked (e.g., re-evaluated) each time the UE switches to a new cell, selects a new cell, or performs a registration area update.

Second, the mechanism of the location criteria may be re-evaluated when URSP is re-evaluated in a timely manner, e.g., when the UE moves from EPC to 5 GC.

Third, the URSP rule may include a timer value that may be used by the UE to determine how often the route should be checked/re-evaluated, e.g., every 1 minute.

Fourth, the URSP rule's RSD may include a time window re-evaluation indication (TWRI) flag whose presence indicates to the UE that the time window information in the RSD should not only be used as a validation criterion when a PDU session is established, but also to determine when the PDU session should be modified or terminated.

Fifth, the RSD of the URSP rule may include a location criteria re-assessment indication (LCRI) flag, the presence of which indicates to the UE that the location criteria information in the RSD should not only be used as a validation criterion when a PDU session is established, but also to determine when the PDU session should be modified or terminated.

Sixth, when the RSD includes a location standard, the network may provide location offset allowance (LDA) in the RSD to the UE. The LDA may indicate to the UE how much the UE's location may deviate from the location criteria after the PDU session is established.

Seventh, the URSP reevaluation, including the location criteria, may be initiated by the UE application based on dropped packets or delay threshold triggers as a response from the edge network or from the UE protocol stack.

Eighth, when the EAS is relocated, the UE may re-evaluate the URSP rules including the location criteria for application of a stream.

Ninth, for an ongoing application flow, the UE may re-evaluate the URSP rule with location criteria to determine if a better route can be selected when the DNS record for EAS is updated or refreshed in the UE.

According to some aspects, 5GC may be enhanced such that when certain conditions are met, the UE may be able to select and replace DNNs in the URSP rules so that the application traffic can use it to reach the required services. According to some aspects, the following enhancements may be made for application triggered DNN replacement:

First, the UE may be configured with DNN replacement rules (which inform the UE to grant or need it under certain conditions) to replace the first DNN provided by the application with the second DNN.

Second, the UE may indicate to the network that it is able to receive DNN replacement rules during UE registration or a UE registration update procedure.

Third, the UE may receive DNN replacement rules (originating from AMF, PCF, and/or UDM/UDR) from the network via NAS messaging.

According to some aspects, the DNN substitution rules may be provided to the UE in an information element separate from URSP rules. Each DNN replacement rule may consist of one or more of "original DNN", "replacement DNN", and service area information to which these rules may be applied. URSP rules may be explicitly linked with DNN substitution rules. The URSP rules may be enhanced so that the network may be included in the indication of whether the DNN provided in the traffic descriptor may not be replaced. Alternatively, the network may provide a "require DNN replacement evaluation" indication in the traffic descriptor or RSD portion of URSP rules to indicate to the UE that URSP rules require that DNN replacement rules also be evaluated with URSP rules.

The UE may provide an indication that it supports receiving DNN replacement rules or that it may request DNN replacement rules. The request may explicitly indicate what original DNN the UE may use.

If no support indication is provided, the UE should indicate to the network that DNN substitution was performed during PDU session establishment. The PDU session establishment request may also provide "original DNN".

The UE may be configured not to apply DNN substitution rules to DNNs derived from LADN information elements. The LADN information element may be updated so that the network may indicate to the UE whether the DNN substitution rules should be applied LADN DNN. If the UE is not in the service area of LADN, the UE may be configured to apply DNN substitution rules only to LADN DNN.

The UE may be able to assist the network by providing the network application with the required information to assist the network in selecting EAS. According to some aspects, the following enhancements may enable 5GC to have this capability:

First, to mitigate uplink packet loss for a UE while facilitating seamless EAS relocation, application Requirement Information (ARI) for applications in the UE is introduced.

Second, the UE may use a PDU session establishment procedure to transmit the ARI to the network (SMF).

Third, the ARI sent by the UE may be used by the SMF to effect a change in UL CL and introduce buffer metrics (e.g., buffer time, buffer capacity) into the PSA UPF for ongoing PDU sessions during EAS relocation.

According to some aspects, the AF impact may also be used to inform the network of metrics required during EAS relocation:

First, a mechanism by which EAS can provide parameters in a suggested ARI format via NEF for CN (SMF) relocation for seamless applications.

Second, based on the AF traffic impact request including the application requirement information, the core network (SMF) may transmit EAS relocation information to the AMF and the UE using a DNN substitution mechanism.

During the EAS relocation procedure, the UE may be required to flush its DNS cache. According to some aspects, the DNS cache may be flushed using the following method:

First, during the EAS discovery process, the associated impact field sent with the DNS re-resolve indication via the PDU session modification command may enable the UE to replace or remove DNS records based on a predefined algorithm. The algorithm may identify network information received in the associated impact field and may selectively replace/remove DNS records. This enables the UE to reduce its DNS resolution time in the future.

5G enhancements allowing greater network control of PDU sessions for UEs

According to current 3GPP specifications, when a trigger condition is met (e.g., a urs p is updated by the PCF, the UE moves from EPC to 5GC, allowed NSSAI or a change of configuration NSSAI, etc.), the URSP rule is re-evaluated in a timely manner. According to some aspects, the 5G system may be enhanced such that the network may configure the UE such that the UE may detect when it needs to check whether the routing verification criteria (e.g., location criteria and time window) associated with the established PDU session are still valid. By configuring the UE to detect when the routing verification criteria are no longer valid, the UE may be able to more quickly detect when a PDU session may be terminated, modified, and/or established.

The trigger for URSP re-evaluation may be initiated by the UE application based on dropped packets or observed delays between the UE and the edge network. In addition, triggers may be sent from the UE protocol stack based on degradation of delay, qoS, etc., indicated by the QFI flag. According to some aspects, the network may be able to include information in URSP rules to help the UE determine when it needs to check whether the routing verification criteria (location criteria and time window) associated with the established PDU session are still valid. For example:

First, the network may indicate in URSP rules that the routing verification criteria need to be checked (e.g., re-evaluated) each time the UE switches to a new cell, selects a new cell, or performs a registration area update. The indication may be sent to the UE in the RSD portion of URSP rules.

Second, the network may indicate a timer value in the URSP rule. The UE may use the timer value to determine how often to check/re-evaluate whether the route is valid. For example, the timer may indicate a value of 1 minute. This may enable the UE to check (e.g., re-evaluate) whether the route is valid every minute.

Third, the URSP rule may be enhanced to include a time window re-evaluation indication (TWRI) flag whose presence indicates to the UE that the time window information in the RSD should not only be used as a validation criterion when a PDU session is established, but also to determine when the PDU session should be modified or terminated.

Fourth, the URSP rule may be enhanced to include a location criteria re-evaluation indication (LCRI) flag whose presence indicates to the UE that the location criteria information in the RSD should not only be used as a validation criterion when a PDU session is established, but also to determine when the PDU session should be modified or terminated.

Fifth, when the RSD includes a location standard, the network may provide location offset allowance (LDA) in the RSD to the UE. The LDA may indicate to the UE how much the UE's location may deviate from the location criteria after the PDU session is established. Once a PDU session is established and the UE detects that its location deviation from the location criteria exceeds LDA, the UE may re-evaluate its URSP rules and terminate or modify the PDU session.

Sixth, the re-evaluation rules may be enhanced URSP so that the location criteria are re-evaluated in a timely manner, such as when URSP is updated by the PCF, the UE moves from EPC to 5GC, allowed NSSAI or a change in configuration NSSAI, etc.

Seventh, when repositioning EAS, the UE needs to re-evaluate URSP rules including location criteria for the same application flow.

Eighth, when updating or refreshing the DNS record of EAS in the UE, the UE may re-evaluate URSP the rules with location criteria for the ongoing application flow to determine if a better route can be selected for the application flow.

It should be noted that the UE may be configured such that the checking (e.g., re-evaluation) VSD is only performed when the UE is in the CM-CONNECTED state.

Note that only URSP rules of the current service in use are re-evaluated when a trigger event for RSD re-evaluation occurs. Alternatively, the UE may maintain a list of URSP rules that have been applied to the active flow and that require or allow re-evaluation.

Table 4 presents RSDs that have been enhanced to include the above fields. Note that "selecting a route" means that the UE selects an existing PDU session that matches the route or determines to establish a PDU session that matches the route.

TABLE 4 enhanced routing description

DNN replacement in UE

The URSP rules may be configured such that when certain conditions are met, the UE will select DNNs that the application traffic can use to reach the required services. The DNN selected may be based on the type of application, application ID, IP address or FQDN being contacted, location of the UE, etc. According to some aspects, the selected DNN may be associated with an edge network when an edge service is available.

Some applications may be designed such that they provide DNN to the UE. For example, the application may provide DNN to the UE when the UE initially generates IP traffic. In this case, URSP rules are not used to select DNNs. Instead, the UE may use DNN provided by the application. The URSP rule can still be used to determine what route should be used to reach the DNN (e.g., what existing or new PDU session should be used to reach the DNN). In this case, the application designer may prefer to design the application such that the application always provides the same DNN to the UE, regardless of what MNO is serving the UE. However, different MNOs may wish to route traffic of an application differently. For example, one MNO may prefer to route application traffic to a special data network dedicated to that application, while another MNO may prefer not to give special treatment to the application's traffic and route that traffic to a data network (e.g., the internet) shared with many other applications.

In another example, edge applications often prefer to send and receive data from an edge data network. According to some aspects, the edge data network is a data network geographically proximate to a UE hosting the edge application. Since each data network may have a different DNN, edge application designers may prefer to design an application such that the application always provides the same DNN to the UE, regardless of which edge data network is closest to the UE.

When considering edge services, it may be desirable to let the UE know that certain DNNs may be associated with edge data networks with different DNNs. For example, the UE may be configured with DNN substitution rules. The DNN replacement rule tells the UE that it is allowed, or that under certain conditions it may be necessary to replace the first DNN provided by the application with the second DNN. For example, the rules may indicate that for certain types of application traffic, when the UE is in A particular location and the DNN is not accessible, or if A given DNN is unable to deliver application service requirements due to traffic or service availability, the UE must replace DNN-A with DNN-B and provide DNN-B to the network when establishing A PDU session.

The UE may indicate to the network (e.g., during registration) that it is capable of receiving DNN replacement rules. According to some aspects, support indication may be desirable because current UE behavior is: if one or more DNNs are included in the service descriptor of the URSP rule and one or more DNNs are included in the routing descriptor, the routing descriptor is ignored, see TS24.526[6]. If the enhanced URSP rule is sent to a UE that does not support the enhancement, it may result in a UE ignoring RSD.

Note that by having the UE apply the DNN replacement rules instead of having the AMF apply the DNN replacement rules, the interaction between the AMF and the PCF that is required to apply the DNN replacement rules in the AMF may be avoided.

The UE may receive the DNN replacement rules from the AMF via NAS messaging. The DNN replacement rules may originate from UDM/UDR, PCF or AMF. DNN substitution rules may be used in combination with URSP rule enhancements.

The DNN substitution rule may be part of the URSP rule. For example, URSP rules may indicate that DNNs may be replaced when an application provides a DNN as part of a service descriptor. The network may indicate this to the UE by including DNNs in both the traffic descriptor and RSD portion of the URSP rule. For example, the old DNN may be provided in the traffic descriptor and the new DNN may be provided in the RSD portion of URSP. Alternatively, the network may provide a separate indication that the UE may preemptively perform DNN replacement for the case where the application provides DNN.

According to some aspects, when the UE sends a PDU session establishment request to the network, the UE may indicate the DNN in a NAS message. The DNN provided by the UE may be an indication of the data network that the UE is requesting to send and receive data to and from the data network using a PDU session. When sending the PDU session establishment request, the UE must determine what DNN to include in the NAS message. When sending the PDU session establishment request, the process of the UE determining what DNN to include in the NAS message may be referred to as "DNN selection".

According to some aspects, the UE may perform DNN substitution. According to some aspects, the DNN substitution may be considered a part of, or a step within, the DNN selection process. According to some aspects, DNN substitution may be performed as a result of DNN selection. The DNN selection may consist of: the UE determines to include the DNN provided by the application in the NAS message when sending the PDU session establishment request. According to some aspects, DNN selection may consist of: the UE determines to include the DNN provided by the application in the NAS message when sending the PDU session modification request. According to some aspects, DNN selection may consist of: the UE determines to include in the NAS message the DNN that was previously provided by the network (e.g., during a previous interaction between the UE and the network) to the UE for the PDU session when the PDU session establishment request or the PDU session modification request was sent. The DNN selection may consist of: the UE evaluates URSP rules to determine the DNN to be included in the NAS message when sending the PDU session establishment request or the PDU session modification request. According to some aspects, the UE may enhance the DNN selection procedure using the described DNN replacement procedure.

According to some aspects, DNN selection, and thus DNN replacement, may be triggered when an application hosted by the UE initiates an application layer service or provides a service descriptor to the UE, e.g., in a modified application layer service (such as DNN).

According to some aspects, the described enhancements to the PDU session establishment procedure may be applied to a PDU session modification procedure such that the UE may request a change in DNN associated with the PDU session. According to some aspects, the UE may use the PDU session modification request to change the DNN associated with the PDU session. This may be used, for example, if the UE moves to LADN available locations and the UE wants to move traffic associated with the PDU session to LADN. When the UE sends a PDU session modification request to the network with the new DNN, the request may trigger SMF and UPF reselection in the network.

Communicating application requirements to a core network

According to some aspects, the DNN substitution rules may be received by the UE. Each rule may consist of the first DNN, the second DNN and service area information to which the rule should be applied.

According to some aspects, the first DNN may be a DNN provided by an application (e.g., provided by the application as part of a traffic descriptor), or the first DNN may be a DNN determined by the UE when it evaluates URSP rules based on applying the traffic descriptor. The first DNN may be referred to as the "original DNN".

According to some aspects, the second DNN may be a replacement DNN. When the UE determines to apply the DNN replacement rule, the UE may replace the first DNN with the second DNN. For example, replacing the first DNN with the second DNN may include transmitting application data using a PDU session associated with the second DNN, which may be referred to as a replacement DNN.

According to some aspects, the service area information to which the rules should be applied is location information indicating to the UE when the rules should be applied. According to some aspects, an advantage of providing service area information in DNN rules may be that it gives the network the ability to tell the UE where it should apply the rules. This may be advantageous in case the second DNN is only available in certain locations and in case the second DNN is only preferred over the first DNN in certain locations. The service area information may be a set of tracking areas, a set of coordinates, or a set of cell IDs in the current registration area.

According to some aspects, the DNN replacement rules may consist of one or more original DNNs and one replacement DNN. For example, the rule may be interpreted by the UE as an instruction to replace the original DNN with a replacement DNN when the UE is in the service area indicated by the rule.

According to some aspects, multiple DNN substitution rules may be provided to the UE, e.g., multiple rules may be applied to the same original DNN. For example, the same original DNN may appear in two different DNN substitution rules. According to some aspects, this type of configuration may be desirable when replacement dnn#1 in service area#1 is applied to replace original DNN and replacement dnn#2 in service area#2 is applied to replace original DNN.

According to some aspects, to simplify encoding of the DNN replacement rules, the UE may be configured to evaluate and apply the DNN replacement rules in a priority order. For example, if the UE is provided with a list of N DNN substitution rules and finds the desired original DNN value in DNN substitution rule #1, the UE may apply DNN substitution rule #1 and not evaluate the subsequent DNN substitution rules (even if the desired original DNN value appears in the other N-1 DNN substitution rules). Alternatively, the subsequent DNN replacement rules may take precedence and the UE may apply the last DNN replacement rule that it evaluates and includes the desired original DNN value.

Table 7 shows an exemplary encoding of the DNN substitution rule information element. According to some aspects, this information element includes one or more DNN substitution rules, and the encoding is further described in table 7.

Table 5-DNN substitution rule information element encoding

Table 6 shows an exemplary encoding of the DNN substitution rule information element. According to some aspects, the information element includes 1 DNN substitution rule.

Table 6-DNN substitution rule information element encoding

Table 7-DNN substitution rule information element

According to some aspects, the DNN substitution rules may be slice-based. For example, the encodings shown in tables 5, 6, and 7 may be enhanced to allow the network to send the UE slice-based DNN replacement rules. For example, the DNN substitution rule information element may indicate to the UE that substitution rules apply only to certain slices. These slices may be identified by S-NSSAI. In another alternative, the DNN substitution rule information element may indicate to the UE that the substitution rule applies only to certain slices.

As described above, the DNN substitution rule may indicate to the UE that the rule is valid only under certain conditions. For example, the rule may include an indication that the rule is valid only in a particular location or when applied to a PDU session associated with a particular S-NSSAI. According to some aspects, DNN replacement rules may include other types of validity conditions. For example, the codes shown in tables 5, 6, and 7 may be enhanced to allow the network to send other types of validity conditions to the UE. Other validity conditions may indicate to the UE that the DNN substitution rules should be applied only at certain times, should not be applied at certain times, should be applied only to LADN, should never be applied to LADN, should be applied only to DNNs provided by an application as part of an application descriptor, should not be applied to DNNs provided by an application as part of an application descriptor, should be applied to certain application types, should not be applied to certain application types, should be applied only to DNNs determined by evaluating RSD, or should not be applied to DNNs determined by evaluating RSD. To apply this rule, the UE may consider any DNN received in LADN information elements to be LADN.

According to some aspects, the DNN replacement rule may include a rule identifier or a rule reference number. For example, the codes shown in tables 5, 6, and 7 may be enhanced to allow the network to include rule identifiers or rule reference numbers. When the UE selects DNN using the DNN replacement rule, the UE may provide a rule identifier or rule reference number to the network to indicate to the network that DNN replacement was performed and further indicate what specific rule was applied.

According to some aspects, the DNN replacement rules may also indicate that "original DNN" is not allowed and may not be replaced with DNN. In other words, the UE may not attempt to establish a PDU session with the DNN.

According to some aspects, the DNN replacement rules may also indicate that "original DNN" is not allowed and that the UE should not include DNN in the PDU session establishment request instead of "original DNN" so that the network will establish a PDU session with the default DNN.

According to some aspects, the DNN replacement rules sent by the AMF to the UE may be received by the AMF from the PCF. For example, the AMF may invoke Npcf _ UEPolicyControl _create request service and receive DNN replacement rules in the response. The DNN replacement rules sent by the AMF to the UE may be received by the AMF from the UDM. For example, the DNN replacement rule may be part of the subscription information of the UE, and the AMF may invoke Nudm _sdm_get request service and receive the DNN replacement rule in a response.

Coordination of support of DNN replacement rules between a UE and a network

According to some aspects, the UE may not support the ability to receive DNN substitution rules. When such a non-supporting UE receives the DNN substitution rule, it may not understand the information element encoding and discard or ignore the information. This is not a desirable situation, because if the UE ignores the DNN substitution rules, the UE will attempt to use the DNN in a manner that is not desirable to the network. For example, this may result in the UE attempting to establish a PDU session towards the DNN in the area where the more optimized DNN is available. For example, this may result in the UE attempting to establish a PDU session with the DNN in the area where the DNN is not available.

According to some aspects, to avoid sending DNN replacement rules to an unsupported UE, the UE may indicate to the network that it supports receiving DNN replacement rules, or indicate to the network that it expects to receive DNN replacement rules. The indication may be sent from the UE to an AMF in the network in a registration request. This indication may be referred to as a DNN substitution rule indication.

According to some aspects, the DNN replacement rule indication may be an indication that the UE supports receiving and applying the DNN replacement rule, and it may further provide the original DNN to the network. The original DNN provided in the DNN replacement rule indication may be a DNN that the UE may be configured to use and/or expect to use. The network may determine which DNN replacement rules to send to the UE based on the original DNNs provided to the AMF by the UE in the DNN replacement rule indication. According to some aspects, an advantage of having the UE provide the original DNN to the AMF in the DNN substitution rule indication is that the network can use this information to determine to reduce the number of DNN substitution rules it sends to the UE. For example, the network may determine to send only the UE DNN replacement rules associated with the original DNN provided by the UE in the DNN replacement rule indication.

Table 8 shows an exemplary encoding of the DNN substitution rule indication information element. The information element may include 0 or more original DNN values. Table 9 provides a further description of the codes shown in table 8.

Table 8-DNN substitution rules indicate information element encoding

Table 9-DNN substitution rule indication

Receiving DNN replacement rules at a UE

According to some aspects, DNN substitution rules (e.g., the information described in tables 5, 6, and 7) may be sent from the AMF to the UE. The AMF may send the DNN replacement rules to the UE in a registration accept message.

According to some aspects, when a UE sends a registration request to a network, the UE may indicate to the network that the UE supports receiving DNN replacement rules. For example, the UE may include a DNN substitution rule indication (e.g., the information described in tables 8 and 9) to the AMF in the registration request message. The presence of the DNN substitution rule indication information element in the registration request message may be an indication from the UE to the network that the UE supports receiving and applying the DNN substitution rule. The inclusion of an optional original DNN value in the DNN replacement rule indication information element may help the network determine which DNN replacement rules to send to the UE.

When the AMF receives the DNN replacement rule indication from the UE, the AMF may store the indication as part of the UE configuration. When the AMF receives the new DNN configuration information, the AMF may then determine to send a new DNN replacement rule to the UE. For example, DNN configuration information may be received from the OAM system and used by the AMF to create the DNN replacement rules. The AMF may use the DNN replacement rule indication in the AMF context of the UE to determine whether to send updated DNN replacement rules to the UE. The AMF may send the updated DNN replacement rules to the UE in a UE configuration update procedure. The AMF may consider the slices in the allowed NSSAI, requested NSSAI, and configured NSSAI of the UE when determining what DNN substitution rules to send to the UE.

Alternatively, the DNN configuration information may also be received from the UDM/UDR after the UDM/UDR receives the DNN configuration information from the NEF. The NEF may receive DNN configuration information when invoking the AF service impact API.

According to some aspects, the AMF may detect other events that would trigger the AMF to send the DNN replacement rules to the UE. For example, the AMF may receive a NAS message from the UE, and the NAS message may indicate that the UE desires to establish a PDU session with a particular DNN or modify a PDU session with the DNN. The AMF may determine that if the UE has properly applied the DNN replacement rule, the UE will replace the provided DNN and include a different DNN in the NAS message. The AMF may then reject the PDU session establishment request. The AMF may also determine that the DNN replacement rules for the UE may not be up-to-date, and the AMF may determine to send a UE configuration update message to the UE with the up-to-date DNN replacement rules. In another example, the UE may provide the DNN substitution rule identifier or DNN substitution rule reference number to the AMF during PDU session establishment. The AMF may determine that the DNN replacement rule identifier or DNN replacement rule reference number expires or a different rule should be applied. The AMF may then reject the PDU session establishment request and send updated DNN replacement rules to the UE. In yet another example, if the subscription information of the UE indicates that the UE supports DNN replacement, the AMF may obtain DNN replacement rules from the UDM/UDR to send to the UE during the registration procedure.

When the PDU session establishment request or PDU modification session request is denied and the AMF determines that the DNN replacement rule in the UE needs to be replaced, the AMF may provide the UE with an indication that the UE may try the PDU session establishment or PDU session modification again only after receiving the new DNN replacement rule.

PDU session establishment or PDU session modification considerations when applying DNN replacement rules

According to some aspects, it may be desirable for a network (e.g., AMF or SMF) to determine whether a UE performed DNN replacement. For example, if the network sends a DNN substitution rule to the UE, and the UE has not previously provided an indication to the network that the UE supports receiving and applying the DNN substitution rule, the network may not know whether the DNN substitution rule is provided. The proposal UE may indicate to the network during the PDU session establishment or PDU session modification procedure whether the DNN being requested in the PDU session establishment request message or in the PDU session modification request message is a replacement name. The network may use this indication to avoid evaluating the requested DNN name to determine if a replacement is needed in the network (e.g., via AMF).

According to some aspects, when the UE sends a PDU session establishment request or a PDU session modification request to the AMF, the message is carried within the UL NAS transport message. The UL NAS transport message also carries the DNN associated with the PDU session establishment request. According to some aspects, the UL NAS transport message may be enhanced to further include an optional "original DNN" field. The presence of the "original DNN" information element in the UL NAS transport message may be an indication that DNN substitution for the AMF was performed by the UE, and the value of the "original DNN" information element in the UL NAS transport message may indicate the substituted DNN value to the AMF.

According to some aspects, the UE may also provide the DNN substitution rule identifier or DNN substitution rule reference number in the UL NAS transport message to the network. The DNN replacement rule identifier or DNN replacement rule reference number is used as an indication of the application of the DNN replacement rule to the AMF and as an indication of what DNN replacement rule to apply.

According to some aspects, if the AMF did not receive the "original DNN" information element in the UL NAS transport message and the AMF did not previously receive an indication of support from the UE (e.g., a DNN substitution rule indication information element), the AMF may evaluate the DNN provided in the UL NAS transport message for the PDU session to determine if it needs substitution. The evaluation operation may require interaction with the PCF to obtain DNN replacement rules and interaction with the SMF to perform SMF selection.

According to some aspects, the "original DNN" value may also be provided to the SMF selected to serve the PDU session. The AMF may provide the value to the SMF when the AMF invokes Nsmf _ PDUSession _ CreateSMContext requesting a service operation, or the UE may provide the value to the SMF by including the value in the PDU session establishment request part of the message. The SMF may use this information to identify the type of application associated with the PDU session and the type of data network to which the traffic should be routed. The SMF may use this information to help select a UPF to service the PDU session. Further, if the SMF determines that a more optimal UPF or DNN may be available based on the location of the UE, the SMF may monitor the location of the UE and change the UPF and/or DNN associated with the PDU session.

When the SMF determines that there is a better DNN to serve the PDU session for the UE, the SMF may send a PDU session modification command to the UE to indicate to the UE that the PDU session is now associated with a new DNN.

According to some aspects, when the SMF determines that there is a better DNN to serve the PDU session of the UE, the SMF may send a PDU session modification command to request the UE to re-evaluate the DNN substitution rules associated with the PDU session. If the UE determines that a more optimized DNN may be associated with the application service, the UE may trigger a PDU session modification request, or the UE may release the PDU session and establish a new PDU session with a new DNN determined using the DNN replacement rules.

According to some aspects, starting with SMF determination that a different DNN should be applied, it may also be used with the mechanism described in the "enhancement of AF traffic impact" clause. For example, the SMF may make this determination when a DNN replacement procedure is initiated in the CN through an AF traffic influencing procedure.

Program supporting reception and application of DNN substitution rules

According to some aspects, fig. 9 illustrates a representation of how a UE may receive and apply DNN substitution rules.

In step 1, the UE may send a registration request to the network. The registration request may include the DNN substitution rule indication information elements described above and shown in tables 8 and 9.

In step 2, the UE may invoke Nudm _sdm_get and indicate to the UDM that the UE supports receiving DNN substitution rules. Nudm _SDM_get can reply to and provide DNN replacement rules to the AMF. The contents of the DNN substitution rules may be as shown in table 5, table 6 and table 7. As previously described and as an alternative to the UE providing the DNN replacement rule indication to the AMF in step 1, the UDM may provide the DNN replacement rule to the AMF based on the information of the UE's support for DNN replacement in the subscription information of the UE stored in the UDM.

In step 3, the AMF may send a registration response to the UE, and the registration response may include DNN substitution rule information elements as shown in tables 5, 6 and 7.

In step 4, the subscription information of the UE may be updated and new DNN substitution rules may be sent to the AMF for the UE.

In step 5, the AMF may send a UE configuration update to the UE and may send a new DNN replacement rule in the DNN replacement rule information elements as shown in table 5, table 6 and table 7.

In step 6, the UE may send an UL NAS transport message to the AMF. The UL NAS transport message may include a PDU session establishment request. As described above, the UL NAS transport message may include an "original DNN" information element. The message may be triggered by an application generating an application layer service and providing DNN to the UE as part of the service descriptor. The DNN provided by the application will be the "original DNN" described earlier.

In step 7, the AMF will call Nsmf _ PDUSession _ CreateSMContext and provide the PDU session setup request to the AMF and the "original DNN" to the SMF. According to some aspects, the UE may already provide the "original DNN" in the PDU session establishment request rather than in the UL NAS transport message.

In step 8, the SMF responds to the UE with Nsmf _ PDUSession _ CreateSMContext response message.

In step 9, the UE receives a DL NAS transport message carrying a PDU session establishment accept.

In step 10, the UE transmits an application service through a PDU session. The application traffic is sent to a data network associated with the replacement DNN.

Applying DNN replacement rules to LADN

According to some aspects, the DNN replacement rules may be from a subscription of the UE or from the PCF in the HPLMN. The LADN information sent to the UE may come from the serving PLMN. For example, the PLMN creating the DNN substitution rule and the PLMN creating LADN information may be different, and the UE may not desire to apply the DNN substitution rule to the DNN received in LADN information. To avoid a conflict between LADN information and DNN replacement rules, the UE may be configured not to apply DNN replacement rules to DNNs derived from LADN information elements.

According to some aspects, LADN information elements may be updated so that the network may indicate to the UE whether DNN substitution rules should be applied to LADN DNN. In another alternative, if the UE is not in the service area of LADN, the UE may be configured to apply DNN substitution rules only to LADN DNN.

Indicating when a UE applies DNN replacement rules

According to some aspects, the format of the RSD or traffic descriptor in the URSP rules may be enhanced so that the network may contain an indication of whether the DNN provided in the traffic descriptor may not be replaced. If the non-supporting UE receives URSP rule with the new "perform DNN replacement" indication, the non-supporting UE will ignore the URSP rule because it contains parameters that it does not understand. Thus, the network may address backward compatibility by sending to the UE a lower priority version with a new "do DNN replace" indication URSP rule and no "do DNN replace" indication URSP rule. According to some aspects, a non-supporting UE may always apply URSP rules without a new "perform DNN replace" indication and ignore URSP rules that it does not understand, and a supporting UE will always apply URSP rules of higher priority that include a new "perform DNN replace" indication.

According to some aspects, the network may indicate to the UE that DNN substitution is required by including DNN in both the traffic descriptor and RSD portion of the URSP rule. According to some aspects, the network may provide a "require DNN replacement evaluation" indication in the traffic descriptor or RSD portion of URSP rules to indicate to the UE that URSP rules require that DNN replacement rules also be evaluated with URSP rules. For example, URSP rules determined via URSP evaluation are subject to DNN substitution. If the non-supporting UE receives URSP rule with the new "needed DNN replacement evaluation" indication, the non-supporting UE may ignore the URSP rule because it contains the "needed DNN replacement evaluation" indication that it does not understand. Thus, according to some aspects, the network may consider backward compatibility by sending to the UE a lower priority version of URSP rule with a new "need DNN replacement evaluation" indication and URSP rule without a "need DNN replacement evaluation" indication. According to some aspects, a non-supporting UE may always apply URSP rules without a new indication and ignore URSP rules that it does not understand, and a supporting UE may always apply higher priority URSP rules including a new "need DNN replacement evaluation" indication.

According to some aspects, the network may indicate to the UE that a DNN replacement is required by including one or more DNN replacement rule identifiers or rule reference numbers in a new field in the UOSP rule. For example, an identifier or reference number may link DNN replacement functionality with URSP rules and indicate to the UE that DNN replacement should be performed.

Communicating application requirements to a core network

The AF/SMF may trigger an EAS relocation procedure based on internal information such as congestion conditions, failure of the EAS itself, or UE mobility. Once the target DNAI is determined, the SMF may select a new local PSA and establish a session with the new local PSA. When the SMF sends N6 traffic routing information to the new local PSA, the SMF also instructs the local PSA to buffer upstream data.

Each UE application may have its own requirements. Depending on the type of application, the application may have a delay tolerance or minimum data rate to function at an acceptable level. According to some aspects, these application characteristics may vary from one application to another.

According to the same aspect, it may be appropriate for the core network to have information about the requirements of each application. For example, this information may be used by the network to determine whether and when to direct traffic of the UE to a particular edge data network (e.g., identified by DNAI).

According to some aspects, the following UE application information may be communicated by the UE to the core network, the following mechanisms may be used by the UE to communicate such information to the core network, and the following methods may use this information for graceful EAS relocation.

UE application requirement information

The UE application requirement information may include, but is not limited to, the information depicted in table 10.

TABLE 10 UE application requirement information

Transmitting application requirements during a PDU session establishment procedure

The application requirement information described in table 10 may be transferred to the core network during a PDU session establishment or PDU session modification procedure as described in fig. 2.

In step 0-a, the UE may download the application from a central data network (e.g., cloud, internet) or an edge network. The UE may also download only a portion of the application software (e.g., a new version, an update, etc.), or may request and receive an authorization command (e.g., for authenticity, integrity) when the application software is installed, whether or not the application software is downloaded from the data network.

Step 0-B may be performed independently or may be performed in coordination with step 0-a. In step 0-B, the UE may also contact the central data network for authorization or integrity checking during the application installation process.

In step 1, the UE may send a request for PDU session establishment to the SMF via the AMF. The NAS message may include information such as S-NSSAI and DNN requested by the UE. In addition, the UE NAS message may further include Application Requirement Information (ARI) of the requesting application, which may include application requirement data shown in table 10. The UE may include a plurality of ARI information elements. Each ARI may be associated with one or more applications that use the PDU session.

In step 2, the SMF receives the ARI and other information in a PDU session establishment message. The SMF may use ARI information as needed. For example, if the ARI requesting the application includes a region restriction to receive the service of the application, the SMF may update the local policy and enforce the restriction, which even means rejecting the PDU session establishment request. The SMF keeps the other ARI in local memory at least during the lifetime of the PDU session so that this information can be used when needed. For example, the buffer time length may be used only during EAS relocation. Alternatively, the SMF may also use UDM to store ARI and retrieve it when needed. The ARI may be used by the SMF to determine when and if an edge relocation procedure needs to be initiated.

In step 3, the SMF may send a PDU session accept message back to the UE.

Using ARI during EAS relocation

Fig. 3 depicts the process by which the SMF sends the ARI received from the UE (see fig. 2) to the PSA2 UPF during the EAS relocation process, with the ARI being implemented for each application. In addition, the SMF may also change/update UL CL to optimize PDU session procedure based on ARI.

In step 0-a, the SMF saves the ARI received from the UE (see fig. 2).

In step 0-B, the UE has an ongoing PDU session in which UL/DL data is exchanged between the UE, UL CL1UPF, PSA 1UPF and EAS 1.

In step 1, if edge relocation is required, the SMF determines that the local PSA for the PDU session needs to be changed. The SMF may make this determination based on report data provided by the UPF over the N4 interface that does not meet the ARI. Alternatively, the SMF may make this decision based on an indication of data reporting that the ARI provided by the AF is not satisfied.

In step 2, the SMF sends an early notification to the AF after selecting the target PSA (e.g., PSA 2). The AF may indicate that buffering of uplink traffic in PSA2 is required for seamless edge application server relocation.

In step 3, the SMF configures PSA2 as specified in step 2 of clause 4.3.5.6 of TS23.502 and transmits an ARI for each application to PSA2 and instructs PSA2 to buffer uplink traffic for each application based on the transmitted ARI. PSA1 (e.g., source PSA) keeps receiving downlink traffic from EAS1 and sending it to the UE until it is deactivated.

Additionally, based on the ARI received from the UE application, the SMF determines to use the new ULCL and needs to remove the old ULCL for better performance (ULCL 1). The SMF may select or initiate/initiate UL CL 2/branch point UPF functions. The insertion of UL CL2/BP may depend on the application requirements and the nature and amount of traffic from the UE. For example, if UL data rates are high, data is frequent, applications require command hard delay criteria, and old UL/CL is limited in its capacity and/or ability to handle such traffic, then ARI may trigger such insertion. The SMF may be able to set a threshold for data traffic and to comprehend the ARI from the UE to insert such UL CL UPF.

If a new UL CL (UL CL 2) is not inserted, the SMF may continue to use UL CL1 during the EAS relocation procedure. Therefore, in this case, all functions of UL CL2 can be performed by UL CL1.

In step 4, the SMF may select UL CL2 and send an N4 session modification request to UL CL2 to convey UL CL rules for the traffic flow. This may include information about the SMF attempting to move from PSA1 to PSA 2.

In step 5, the SMF modifies the PDU session so that the session is conducted through UL CL2 and PSA 1.

In step 6, the UE may undergo an EAS retransmission process based on the information received in step 5.

In step 7, the UL CL2 UPF may send an end of packet flag to PSA1 indicating the end of the PDU packet, which PSA1 then forwards to the source EAS. After receiving the end of packet marker, the source EAS stops processing the packet and EAS relocation may begin.

Step 4-a is an alternative step for the case where UL CL/BP is not changed. In this case, the SMF sends an N4 session modification request to UL CL1 to update rules regarding traffic flows that the SMF attempts to move from PSA1 to PSA 2.

Step 7-a is an alternative step, for example in case the UL CL/BP remains the same. In this case, UL CL1 UPF may send an end-of-packet marker to PSA1, which PSA1 then forwards to the source EAS. After receiving the end of packet marker, the source EAS stops processing the packet and EAS relocation may begin.

Meanwhile, in step 8, the UE may transmit UL data to the UL CL2UPF, and the UL CL2UPF may forward the UL data to the PSA 2. Based on the ARI of each application, PSA2 can establish a buffer space and begin buffering UL data for each application involved in the PDU session.

In steps 9, 10 and 11, the SMF sends a delay notification to the AF. When the EAS relocation is complete, the AF sends a delay notification response to the SMF.

In step 12, PSA1 is deactivated and PSA2 is directed to transmit UPF data to EAS2 via the N6 interface.

In step 13, the buffered data in PSA2 for each application is sent to EAS2 via the N6 interface.

Step 14 describes that the PDU session is conducted by UL CL2 and PSA2 UPF. UL/DL packets from UL CL2 may be exchanged with PSA2 using an N9 interface. PSA2 uses the N6 interface for UL/DL traffic with EAS 2.

Enhancement of AF business impact procedure

According to some aspects, a UE-based mechanism for DNN replacement and application requirements to provide EAS relocation is provided. AF traffic impact procedure enhancements are also provided as an alternative to both DNN replacement and providing application requirements to the core network. According to some aspects, the enhancements provided to use the AF traffic influencing APIs or procedures may be implemented using other network exposure APIs as desired.

When performing EAS relocation, the AF traffic influencing procedure is triggered by the coordinator AF (e.g., EES) or by the source or target EAS. The EAS may provide the information needed for the DNN replacement mechanism to occur in the 5GC by the AF traffic impact request as shown in table 11. Based on this proposal, the EAS can also provide parameters to be used by the CN via the NEF when performing application relocation. Note that table 11 provides examples of parameters such as buffering and delay, which may be provided in other formats, such as the ARI provided.

TABLE 11 Business impact AF request, e.g., based on TS23.501 TABLE 5.6.7-1

The AF traffic impact may be used as described in 3gpp ts23.502 clause 4.3.6.2 and shown in fig. 4, with the following enhancements:

after storing the information at the UDR, a notification with applicable PCC rules for DNN replacement and application requirements for EAS relocation is sent via the PCF to the SMF. The PCF provides DNN replacement decisions to the AMF as described in TS 23.501.

The SMF may configure the UPF with newly received information regarding the application requirements for EAS relocation. For example, the "use ARI during EAS relocation" procedure described previously for ARI may also be used in this solution when AF provides ARI or other application requirements for EAS relocation.

In step 6 of fig. 4, the SMF uses the newly received information to enhance the user plane reconfiguration. For example, given EAS relocation requirements, user plane reconfiguration may be based on the session continuity procedure detailed in TS23.502 clause 4.3.5.

SSC pattern 3 example using the session continuity mechanism in TS23.502 clause 4.3.5. Step 2, step 6 (user plane reconfiguration) in fig. 4 may comprise the steps detailed in fig. 5.

When applied to EAS relocation situations, in the process, the SMF may also determine an endpoint change of the traffic flow, e.g. based on the AF traffic impact request, in step 1. The proposed enhancement of SF traffic impact requests also provides the SMF with information about application requirements for DNN replacement and EAS relocation before performing session continuity procedures.

In steps 2 and 3, the SMF sends DNN substitution information to the AMF and the UE via Namf _communication_n1n MESSAGETRANSFER and PDU session modification command, respectively. This allows the DNN replacement mechanism to be used not only at PDU session establishment as detailed in TS23.501, but also at EAS relocation. In addition, if the DNN replacement is not temporary or local, it allows the UE to be informed of the DNN replacement policy for future use.

Flushing DNS caches in UEs for EAS discovery

When the EAS serving the UE is relocated, the SMF may send an indication to the UE that DNS cache refresh operations are needed. The DNS cache flush indication may be associated with additional information to help the UE determine which DNS cache entries should be flushed. For example, a DNS cache flush indication may be associated with a FQDN whose entry should be flushed while other entries do not need to be flushed. The UE DNS cache flushing method is depicted in fig. 6.

In step 0, UL/DL data is exchanged between the UE and the edge network/EAS using UL CL1 and PSA 1.

In step 1, the SMF determines that the path using ULCL a and PSA1 may not be ideal when the UE moves. The SMF may have detected that the UE enters a new location. The SMF decides to use a new PSA UPF (PSA 1) and can insert UL CL2.

In step 2, the SMF may send an EAS rediscover indication to the UE via the PDU session modification command, the EAS rediscover indication including a DNS re-resolve indication and its optional association effect field within the NAS message. The optional association effect field may include zone information, network information such as IP segments, subnet information, FQDN lists, and/or DNS suffixes of new edge servers whose cache entries should be flushed.

In step 3, the UE may replace or refresh (e.g., remove) the DNS record associated with the request of step 2. According to some aspects, the DNS cache flushing process may depend on a predefined algorithm that identifies network information received in an associated impact field (via NAS messaging) and may selectively replace/remove DNS cache records.

In step 4, the UE may discover a new EAS using new ULCL (ULCL 2) and PSA 2.

GUI

Fig. 7 shows a UE with DNS cache requiring selective purging, application Requirement Information (ARI) for each application, and URSP rules with enhanced RSD. When downloading and installing applications, the ARI for each application may be downloaded.

Exemplary communication System

The 3 rd generation partnership project (3 GPP) developed technical standards for cellular telecommunication network technology including radio access, core transport network and service capabilities, including research on codec, security and quality of service. Recent Radio Access Technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), LTE advanced standards, and new air interface (NR) (also referred to as "5G"). The 3GPP NR standards are expected to continue to evolve and include definitions of next generation radio access technologies (new RATs), which are expected to provide new flexible radio access below 7GHz and new ultra mobile broadband radio access above 7 GHz. The flexible radio access is intended to include new non-backward compatible radio access in the new spectrum below 7GHz and to include different modes of operation that can be multiplexed together in the same spectrum to address a broad set of 3GPP NR use cases with different requirements. Ultra mobile broadband is expected to include the centimeter and millimeter wave spectrum that would provide opportunities for ultra mobile broadband access such as indoor applications and hotspots. In particular, ultra mobile broadband is expected to share a common design framework with flexible radio access below 7GHz, with centimeter wave and millimeter wave specific design optimizations.

3GPP has identified a variety of use cases that NR expects to support, resulting in a wide variety of user experience requirements for data rate, delay, and mobility. The use cases include the following general categories: enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC), large-scale machine type communications (mMTC), network operations (e.g., network slicing, routing, migration and interworking, energy saving), and enhanced vehicle-to-vehicle (eV 2X) communications, which may include any of vehicle-to-vehicle communications (V2V), vehicle-to-infrastructure communications (V2I), vehicle-to-network communications (V2N), vehicle-to-pedestrian communications (V2P), and vehicle communications with other entities. Specific services and applications in these categories include, for example, monitoring and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, cloud-based wireless offices, first-responder connections, car emergency calls, disaster alerts, real-time games, multi-person video calls, autonomous driving, augmented reality, haptic internet, virtual reality, home automation, robotics, and drones, among others. All of these and other uses are contemplated herein.

Fig. 9A illustrates an exemplary communication system 100 in which the systems, methods, and apparatus described and claimed herein may be used. The communication system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and/or 102g, which are commonly or collectively referred to as WTRU 102 or WTRUs 102. Communication system 100 may include Radio Access Networks (RANs) 103/104/105/103b/104b/105b, core networks 106/107/109, public Switched Telephone Networks (PSTN) 108, the internet 110, other networks 112, and network services 113. 113. Web services 113 may include, for example, V2X servers, V2X functions, proSe servers, proSe functions, ioT services, video streaming, and/or edge computation, etc.

It should be appreciated that the concepts disclosed herein may be used with any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102 may be any type of apparatus or device configured to operate and/or communicate in a wireless environment. In the example of fig. 9A, each of the WTRUs 102 is depicted in fig. 9A-9E as a handheld wireless communicator. It should be appreciated that in the context of various use cases contemplated for wireless communications, each WTRU may include or be included in any type of apparatus or device configured to transmit and/or receive wireless signals, including by way of example only: user Equipment (UE), mobile station, fixed or mobile subscriber unit, pager, cellular telephone, personal Digital Assistant (PDA), smart phone, laptop, tablet computer, netbook, notebook computer, personal computer, wireless sensor, consumer electronics device, wearable device (such as a smart watch or smart garment), medical device or electronic health device, robot, industrial equipment, drone, carrier such as a car, truck, train or airplane, or the like.

Communication system 100 may also include a base station 114a and a base station 114b. In the example of fig. 9A, each base station 114a and 114b is depicted as a single element. In practice, base stations 114a and 114b may include any number of interconnected base stations and/or network elements. The base station 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, and 102c to facilitate access to one or more communication networks, such as the core networks 106/107/109, the internet 110, the network services 113, and/or the other networks 112. Similarly, the base station 114B may be any type of device configured to interface, wired and/or wireless, with at least one of a Remote Radio Head (RRH) 119A, 119B, a Transmission and Reception Point (TRP) 119A, 119B, and/or a roadside unit (RSU) 120a and 120B to facilitate access to one or more communication networks, such as the core network 106/107/109, the internet 110, the other network 112, and/or the network service 113. The RRHs 119A, 119B may be any type of device configured to wirelessly interface with at least one of the WTRUs 102 (e.g., the WTRU102 c) to facilitate access to one or more communication networks (such as the core networks 106/107/109, the internet 110, the network services 113, and/or the other networks 112).

The TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as the core networks 106/107/109, the internet 110, the network services 113, and/or the other networks 112. RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of WTRUs 102e or 102f to facilitate access to one or more communication networks, such as core networks 106/107/109, internet 110, other networks 112, and/or network services 113. As an example, the base stations 114a, 114B may be Base Transceiver Stations (BTSs), node bs, evolved node bs, home evolved node bs, next generation node bs (gNode bs), satellites, site controllers, access Points (APs), wireless routers, and the like.

Base station 114a may be part of RANs 103/104/105 that may also include other base stations and/or network elements (not shown), such as Base Station Controllers (BSCs), radio Network Controllers (RNCs), relay nodes, and the like. Similarly, base stations 114b may be part of RANs 103b/104b/105b, which may also include other base stations and/or network elements (not shown), such as BSCs, RNCs, relay nodes, and the like. Base station 114a may be configured to transmit and/or receive wireless signals within a particular geographic area, which may be referred to as a cell (not shown). Similarly, the base station 114b may be configured to transmit and/or receive wired and/or wireless signals within a particular geographic area, which may be referred to as a cell (not shown). The cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, for example, base station 114a may include three transceivers, e.g., one for each sector of a cell. Base station 114a may employ multiple-input multiple-output (MIMO) technology and thus may utilize multiple transceivers for each sector of a cell, for example.

The base station 114a may communicate with one or more of the WTRUs 102a, 102b, 102c, and 102g over an air interface 115/116/117, which may be any suitable wireless communication link (e.g., radio Frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Any suitable Radio Access Technology (RAT) may be used to establish the air interfaces 115/116/117.

The base station 114b may communicate with one or more of the RRHs 119A and 119B, TRP a and 119b and/or RSUs 120a and 120b over a wired or air interface 115b/116b/117b, which may be any suitable wired communication link (e.g., cable, fiber optic, etc.) or wireless communication link (e.g., RF, microwave, IR, UV, visible light, centimeter wave, millimeter wave, etc.). Any suitable RAT may be used to establish the air interfaces 115b/116b/117b.

The RRHs 119A, 119b, trps 119A, 119b, and/or RSUs 120a, 120b may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f over an air interface 115c/116c/117c, which may be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet UV, visible, centimeter wave, millimeter wave, etc.). Any suitable RAT may be used to establish the air interfaces 115c/116c/117c.

The WTRUs 102 may communicate with each other over a direct air interface 115d/116d/117d, such as a side link communication, which may be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet UV, visible, centimeter wave, millimeter wave, etc.). Any suitable RAT may be used to establish the air interfaces 115d/116d/117d.

Communication system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, or the like. For example, a base station 114a in RAN 103/104/105 and a WTRU 102a, 102b, 102c or an RRH 119A, 119B in RAN 103b/104b/105b, TRP 119A, 119b and/or RSUs 120a and 120b and WTRUs 102c, 102d, 102e and 102f may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) terrestrial radio access (UTRA) that may use Wideband CDMA (WCDMA) to establish air interfaces 115/116/117 and/or 115c/116c/117c, respectively. WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and/or evolved HSPA (hspa+). HSPA may include High Speed Downlink Packet Access (HSDPA) and/or High Speed Uplink Packet Access (HSUPA).

Base station 114a in RAN 103/104/105 and the WTRUs 102a, 102b, 102c and 102g or RRHs 119A and 119B in RAN 103b/104b/105b, TRPs 119A and 119b and/or RSUs 120a and 120b and WTRUs 102c, 102d may implement a radio technology such as evolved UMTS terrestrial radio Access (E-UTRA) that may use, for example, long Term Evolution (LTE) and/or LTE advanced (LTE-A) to establish air interfaces 115/116/117 or 115c/116c/117c, respectively. The air interfaces 115/116/117 or 115c/116c/117c may implement 3GPP NR techniques. LTE and LTE-a technologies may include LTE D2D and/or V2X technologies and interfaces (such as side link communications, etc.). Similarly, 3GPP NR techniques can include NR V2X techniques and interfaces (such as side link communications, etc.).

Base station 114a in RAN 103/104/105 and WTRUs 102a, 102b, 102c, and 102g or RRHs 119A and 119B, TRP a and 119b and/or RSUs 120a and 120b in RAN 103b/104b/105b and WTRUs 102c, 102d, 102e, and 102f may implement radio technologies such as: IEEE 802.16 (e.g., worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000 1X, CDMA EV-DO, tentative standard 2000 (IS-2000), tentative standard 95 (IS-95), tentative standard 856 (IS-856), global system for mobile communications (GSM), enhanced data rates for GSM evolution (EDGE), GSM EDGE (GERAN), and the like.

The base station 114c in fig. 9A may be, for example, a wireless router, home node B, home evolved node B, or access point, and may utilize any suitable RAT to facilitate wireless connectivity in local areas such as business, home, carrier, train, antenna, satellite, factory, campus, etc. Base station 114c and WTRU 102 (e.g., WTRU 102 e) may implement a radio technology such as IEEE 802.11 to establish a Wireless Local Area Network (WLAN). Similarly, the base station 114c and the WTRU 102 (e.g., WTRU 102 d) may implement a radio technology such as IEEE 802.15 to establish a Wireless Personal Area Network (WPAN). The base station 114c and WRTU 102 (e.g., WTRU 102 e) may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish a pico cell or femto cell. As shown in fig. 9A, the base station 114c may have a direct connection with the internet 110. Thus, the base station 114c may not need to access the Internet 110 via the core network 106/107/109.

The RANs 103/104/105 and/or the RANs 103b/104b/105b may communicate with a core network 106/107/109, which may be any type of network configured to provide voice, data, messages, authorization and authentication, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102. For example, core networks 106/107/109 may provide call control, billing services, mobile location based services, prepaid calls, internet connections, packet data network connections, ethernet connections, video distribution, etc., and/or perform advanced security functions such as user authentication.

Although not shown in fig. 9A, it should be appreciated that RANs 103/104/105 and/or RANs 103b/104b/105b and/or core networks 106/107/109 may communicate directly or indirectly with other RANs that employ the same RAT as RANs 103/104/105 and/or RANs 103b/104b/105b or a different RAT. For example, in addition to being connected to the RAN 103/104/105 and/or the RAN 103b/104b/105b that may be utilizing an E-UTRA radio technology, the core network 106/107/109 may also communicate with another RAN (not shown) employing a GSM or NR radio technology.

The core networks 106/107/109 may also act as gateways for the WTRU 102 to access the PSTN 108, the internet 110, and/or other networks 112. PSTN 108 may include circuit-switched telephone networks that provide Plain Old Telephone Services (POTS). The internet 110 may include a global system for interconnecting computer networks and devices using common communication protocols, such as Transmission Control Protocol (TCP), user Datagram Protocol (UDP), and Internet Protocol (IP) in the TCP/IP internet protocol suite. Other networks 112 may include wired or wireless communication networks owned and/or operated by other service providers. For example, network 112 may include any type of packet data network (e.g., an IEEE 802.3 Ethernet network) or another core network connected to one or more RANs, which may employ the same RAT as RAN 103/104/105 or RAN 103b/104b/105b or a different RAT.

Some or all of the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f in the communication system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102g shown in fig. 9A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114c, which may employ an IEEE 802 radio technology.

Although not shown in fig. 9A, it should be understood that the user equipment may be wired to the gateway. The gateway may be a Residential Gateway (RG). The RG may provide connectivity to the core network 106/107/109. It should be appreciated that many of the ideas contained herein are equally applicable to UEs that are WTRUs and UEs that connect to a network using a wired connection. For example, the ideas applied to wireless interfaces 115, 116, 117 and 115c/116c/117c are equally applicable to wired connections.

Fig. 9B is a system diagram of an exemplary RAN 103 and core network 106. As described above, RAN 103 may communicate with WTRUs 102a, 102b, and 102c over air interface 115 using UTRA radio technology. RAN 103 may also communicate with core network 106. As shown in fig. 9B, RAN 103 may include node bs 140a, 140B, and 140c, which may each include one or more transceivers for communicating with WTRUs 102a, 102B, and 102c over air interface 115. Node bs 140a, 140B, and 140c may each be associated with a particular cell (not shown) within RAN 103. RAN 103 may also include RNCs 142a, 142b. It should be appreciated that RAN 103 may include any number of node bs and Radio Network Controllers (RNCs).

As shown in fig. 9B, the node bs 140a, 140B may communicate with the RNC 142 a. In addition, node B140 c may communicate with RNC 142B. Node bs 140a, 140B, and 140c may communicate with respective RNCs 142a and 142B via Iub interfaces. The RNCs 142a and 142b may communicate with each other via an Iur interface. Each of the RNCs 142a and 142B may be configured to control the respective node B140a, 140B, and 140c to which it is connected. Furthermore, each of the RNCs 142a and 142b may be configured to perform or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, and the like.

The core network 106 shown in fig. 9B may include a Media Gateway (MGW) 144, a Mobile Switching Center (MSC) 146, a Serving GPRS Support Node (SGSN) 148, and/or a Gateway GPRS Support Node (GGSN) 150. Although each of the foregoing elements are depicted as part of the core network 106, it should be understood that any of these elements may be owned and/or operated by an entity other than the core network operator.

The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, and 102c with access to a circuit-switched network, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and conventional landline communication devices.

The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. SGSN 148 may be coupled to GGSN 150.SGSN 148 and GGSN 150 may provide WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as internet 110, to facilitate communications between WTRUs 102a, 102b, and 102c and IP-enabled devices.

The core network 106 may also be connected to other networks 112, which may include other wired or wireless networks owned and/or operated by other service providers.

Fig. 9C is a system diagram of an exemplary RAN 104 and core network 107. As noted above, the RAN 104 may communicate with the WTRUs 102a, 102b, and 102c over the air interface 116 using an E-UTRA radio technology. RAN 104 may also communicate with core network 107.

RAN 104 may include enodebs 160a, 160B, and 160c, but it should be understood that RAN 104 may include any number of enodebs. The enode bs 160a, 160B, and 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102B, and 102c over the air interface 116. For example, the evolved node bs 160a, 160B, and 160c may implement MIMO technology. Thus, the enode B160 a may use multiple antennas to transmit wireless signals to and receive wireless signals from the WTRU 102a, for example.

Each of the evolved node bs 160a, 160B, and 160c may be associated with a particular cell (not shown) and may be configured to process radio resource management decisions, handover decisions, user scheduling in the uplink and/or downlink, and so on. As shown in fig. 9C, the enode bs 160a, 160B, and 160C may communicate with each other through an X2 interface.

The core network 107 shown in fig. 9C may include a mobility management gateway (MME) 162, a serving gateway 164, and a Packet Data Network (PDN) gateway 166. Although each of the foregoing elements are depicted as part of the core network 107, it should be appreciated that any of these elements may be owned and/or operated by an entity other than the core network operator.

MME 162 may be connected to each of evolved node bs 160a, 160B, and 160c in RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, and 102c, bearer activation/deactivation, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, and 102c, and the like. MME 162 may also provide control plane functionality for switching between RAN 104 and other RANs (not shown) employing other radio technologies, such as GSM or WCDMA.

Service gateway 164 may be connected to each of evolved node bs 160a, 160B, and 160c in RAN 104 via an S1 interface. The serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, and 102 c. The serving gateway 164 may also perform other functions such as anchoring user planes during inter-enode B handover, triggering paging, managing and storing the contexts of the WTRUs 102a, 102B and 102c when downlink data is available to the WTRUs 102a, 102B and 102c, etc.

The serving gateway 164 may also be connected to a PDN gateway 166 that may provide the WTRUs 102a, 102b, and 102c with access to a packet-switched network, such as the internet 110, to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

The core network 107 may facilitate communication with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to a circuit-switched network (such as the PSTN 108) to facilitate communications between the WTRUs 102a, 102b, and 102c and conventional landline communication devices. For example, the core network 107 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to the network 112, which may include other wired or wireless networks owned and/or operated by other service providers.

Fig. 9D is a system diagram of an exemplary RAN 105 and core network 109. RAN 105 may communicate with WTRUs 102a and 102b over an air interface 117 using NR radio technology. RAN 105 may also communicate with core network 109. A non-3 GPP interworking function (N3 IWF) 199 may communicate with WTRU 102c over air interface 198 using non-3 GPP radio technology. The N3IWF 199 may also be in communication with the core network 109.

RAN 105 may include next generation node bs 180a and 180B. It should be appreciated that the RAN 105 may include any number of next generation node bs. The next generation node bs 180a and 180B may each include one or more transceivers for communicating with the WTRUs 102a and 102B over the air interface 117. When using integrated access and backhaul connections, the same air interface may be used between the WTRU and the next generation node B, which may be the core network 109 via one or more gnbs. The next generation node bs 180a and 180B may implement MIMO, MU-MIMO, and/or digital beamforming techniques. Thus, the next generation node B180 a may, for example, use multiple antennas to transmit wireless signals to the WTRU 102a and to receive wireless signals from the WTRU 102 a. It should be appreciated that other types of base stations, such as enode bs, may be employed by RAN 105. It should also be appreciated that the RAN 105 may employ more than one type of base station. For example, the RAN may employ an evolved node B and a next generation node B.

The N3IWF 199 may include a non-3 GPP access point 180c. It should be appreciated that the N3IWF 199 may include any number of non-3 GPP access points. The non-3 GPP access point 180c can include one or more transceivers for communicating with the WTRU 102c over the air interface 198. The non-3 GPP access point 180c can communicate with the WTRU 102c over the air interface 198 using an 802.11 protocol.

Each of the next generation node bs 180a and 180B may be associated with a particular cell (not shown) and may be configured to process radio resource management decisions, handover decisions, user scheduling in the uplink and/or downlink, and so on. As shown in fig. 9D, the next generation node bs 180a and 180B may communicate with each other, for example, through an Xn interface.

The core network 109 shown in fig. 9D may be a 5G core network (5 GC). The core network 109 may provide a variety of communication services to clients interconnected by a radio access network. The core network 109 includes a plurality of entities that perform the functionality of the core network. As used herein, the term "core network entity" or "network function" refers to any entity that performs one or more functions of the core network. It should be appreciated that such core network entities may be logical entities implemented in the form of computer-executable instructions (software) stored in and executed on a processor of an apparatus or computer system configured for wireless and/or network communications, such as system 90 shown in fig. 9G.

In the example of fig. 9D, the 5G core network 109 may include an access and mobility management function (AMF) 172, a Session Management Function (SMF) 174, user Plane Functions (UPFs) 176a and 176b, a user data management function (UDM) 197, an authentication server function (AUSF) 190, a Network Exposure Function (NEF) 196, a Policy Control Function (PCF) 184, a non-3 GPP interworking function (N3 IWF) 199, a User Data Repository (UDR) 178. Although each of the foregoing elements are depicted as part of the 5G core network 109, it should be understood that any of these elements may be owned and/or operated by an entity other than the core network operator. It should also be understood that the 5G core network may not include all of these elements, may include additional elements, and may include multiple instances of each of these elements. Fig. 9D shows the network functions directly connected to each other, however, it should be understood that they may communicate via a routing agent such as a diameter routing agent or a message bus.

In the example of fig. 9D, the connection between network functions is implemented via a set of interfaces or reference points. It should be appreciated that a network function may be modeled, described, or implemented as a set of services invoked or called by other network functions or services. Invocation of the network function service may be accomplished via a direct connection between network functions, message exchange over a message bus, invocation of a software function, and the like.

AMF 172 may be connected to RAN 105 via an N2 interface and may function as a control node. For example, AMF 172 may be responsible for registration management, connection management, reachability management, access authentication, access authorization. The AMF may be responsible for forwarding the user plane tunnel configuration information to the RAN 105 via the N2 interface. AMF 172 may receive user plane tunnel configuration information from the SMF via the N11 interface. The AMF 172 may generally route and forward NAS packets to/from the WTRUs 102a, 102b, and 102c via the N1 interface. The N1 interface is not shown in fig. 9D.

SMF 174 may be connected to AMF 172 via an N11 interface. Similarly, the SMF may be connected to PCF 184 via an N7 interface and to UPFs 176a and 176b via an N4 interface. The SMF 174 may be used as a control node. For example, the SMF 174 may be responsible for session management, IP address assignment for the WTRUs 102a, 102b, and 102c, management and configuration of traffic steering rules in the UPF 176a and the UPF 176b, and generation of downlink data notifications to the AMF 172.

The UPFs 176a and 176b may provide the WTRUs 102a, 102b, and 102c with access to a Packet Data Network (PDN), such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and other devices. The UPFs 176a and 176b may also provide the WTRUs 102a, 102b, and 102c with access to other types of packet data networks. For example, the other network 112 may be an ethernet network or any type of network that exchanges data packets. UPF 176a and UPF 176b may receive traffic steering rules from SMF 174 via an N4 interface. The UPFs 176a and 176b may provide access to the packet data network by connecting to the packet data network via an N6 interface or by connecting to each other and to other UPFs via an N9 interface. In addition to providing access to the packet data network, the UPF 176 may be responsible for packet routing and forwarding, policy rule enforcement, quality of service processing for user plane traffic, downlink packet buffering.

AMF 172 may also be connected to N3IWF 199, for example, via an N2 interface. The N3IWF facilitates the connection between the WTRU 102c and the 5G core network 170, for example, via radio interface technologies that are not defined by 3 GPP. The AMF may interact with the N3IWF 199 in the same or similar manner as it interacts with the RAN 105.

PCF 184 may be connected to SMF 174 via an N7 interface, AMF 172 via an N15 interface, and Application Function (AF) 188 via an N5 interface. The N15 and N5 interfaces are not shown in fig. 9D. PCF 184 may provide policy rules to control plane nodes such as AMF 172 and SMF 174, allowing the control plane nodes to enforce these rules. PCF 184 may send policies for WTRUs 102a, 102b, and 102c to AMF 172 such that the AMF may deliver the policies to WTRUs 102a, 102b, and 102c via an N1 interface. Policies may then be enforced or applied at the WTRUs 102a, 102b, and 102 c.

UDR 178 may act as a repository of authentication credentials and subscription information. The UDR may be connected to a network function so that the network function may add to the data in the repository, read the data in the repository and modify the data in the repository. For example, UDR 178 may be connected to PCF 184 via an N36 interface. Similarly, UDR 178 may be connected to NEF 196 via an N37 interface, and UDR 178 may be connected to UDM 197 via an N35 interface.

The UDM 197 may serve as an interface between the UDR 178 and other network functions. The UDM 197 may grant network functions access to the UDR 178. For example, UDM 197 may be connected to AMF 172 via an N8 interface, and UDM 197 may be connected to SMF 174 via an N10 interface. Similarly, UDM 197 may be connected to AUSF to 190 via an N13 interface. UDR 178 and UDM 197 may be tightly integrated.

AUSF 190 perform authentication related operations and connect to UDM 178 via an N13 interface and AMF 172 via an N12 interface.

The NEF 196 exposes the capabilities and services in the 5G core network 109 to the Application Function (AF) 188. Exposure may occur on the N33 API interface. The NEF may be connected to the AF 188 via an N33 interface and may be connected to other network functions in order to expose the capabilities and services of the 5G core network 109.

The application functions 188 may interact with network functions in the 5G core network 109. Interaction between the application function 188 and the network function may occur via a direct interface or may occur via the NEF 196. The application functions 188 may be considered part of the 5G core network 109 or may be deployed outside of the 5G core network 109 and by an enterprise having a business relationship with the mobile network operator.

Network slicing is a mechanism that may be used by a mobile network operator to support one or more "virtual" core networks behind the operator's air interface. This involves "slicing" the core network into one or more virtual networks to support different RANs or different service types running across a single RAN. Network slicing enables operators to create networks tailored to provide optimized solutions for different market scenarios requiring a wide variety of requirements, e.g., in terms of functionality, performance, and isolation.

3GPP has designed 5G core networks to support network slicing. Network slicing is a good tool that network operators can use to support a variety of 5G usage scenarios (e.g., large-scale IoT, critical communications, V2X, and enhanced mobile broadband) that require very diverse and sometimes extreme requirements. Without the use of network slicing techniques, the flexibility and scalability of the network architecture may not be sufficient to effectively support a wider range of use case requirements when each use case has its own set of specific requirements for performance, scalability, and availability. In addition, new network services should be introduced more efficiently.

Referring again to fig. 9D, in a network slice scenario, the WTRU 102a, 102b, or 102c may connect to the AMF 172 via an N1 interface. An AMF may be a logical portion of one or more slices. The AMF may coordinate the connection or communication of the WTRU 102a, 102b, or 102c with one or more of the UPFs 176a and 176b, the SMF 174, and other network functions. Each of the UPFs 176a and 176b, the SMF 174, and other network functions may be part of the same slice or different slices. When they are part of different slices, they may be isolated from each other in the sense that they may utilize different computing resources, security credentials, etc.

The core network 109 may facilitate communications with other networks. For example, the core network 109 may include or may communicate with an IP gateway, such as an IP Multimedia Subsystem (IMS) server, that serves as an interface between the 5G core network 109 and the PSTN 108. For example, the core network 109 may include or be in communication with a Short Message Service (SMS) service center that facilitates communication via a short message service. For example, the 5G core network 109 may facilitate the exchange of non-IP data packets between WTRUs 102a, 102b, and 102c and a server or application function 188. In addition, the core network 170 may provide the WTRUs 102a, 102b, and 102c with access to the network 112, which may include other wired or wireless networks owned and/or operated by other service providers.

The core network entities described herein and shown in fig. 9A, 9C, 9D and 9E are identified by giving these entities names in some existing 3GPP specifications, but it should be understood that these entities and functions may be identified by other names in the future, and that some entities or functions may be combined in specifications that are disclosed by the 3GPP in the future, including future 3GPP NR specifications. Thus, the particular network entities and functions described and illustrated in fig. 9A, 9B, 9C, 9D, and 9E are provided by way of example only, and it should be understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether currently defined or defined in the future.

Fig. 9E illustrates an exemplary communication system 111 in which the systems, methods, and apparatus described herein may be used. The communication system 111 may include a wireless transmit/receive unit (WTRU) A, B, C, D, E, F, a base station gNB 121, a V2X server 124, and Road Side Units (RSUs) 123a and 123b. Indeed, the concepts presented herein may be applied to any number of WTRUs, base stations gNB, V2X networks, and/or other network elements. One or several or all of WTRUs a, B, C, D, E, and F may be outside the range of the access network coverage 131. WTRUs a, B, and C form a V2X group, where WTRU a is the group leader and WTRUs B and C are group members.

If WTRUs a, B, C, D, E, and F are within access network coverage 131, they may communicate with each other over Uu interface 129 via the gNB 121. In the example of fig. 9E, WTRUs B and F are shown within access network coverage 131. WTRUs a, B, C, D, E, and F may communicate directly with each other via a side-link interface (e.g., PC5 or NR PC 5), such as interfaces 125a, 125b, or 128, whether they are within access network coverage 131 or outside access network coverage 131. For example, in the example of fig. 9E, WRTU D outside of access network coverage 131 communicates with WTRU F inside of coverage 131.

WTRUs a, B, C, D, E, and F may communicate with RSU 123a or 123b via a vehicle-to-network (V2N) 133 or a side-link interface 125 b. WTRUs a, B, C, D, E, and F may communicate with V2X server 124 via a vehicle-to-infrastructure (V2I) interface 127. WTRUs a, B, C, D, E, and F may communicate with another UE via a vehicle-to-pedestrian (V2P) interface 128.

Fig. 9F is a block diagram of an exemplary apparatus or device WTRU 102 (such as WTRU 102 of fig. 9A, 9B, 9C, 9D, or 9E) that may be configured for wireless communication and operation in accordance with the systems, methods, and apparatus described herein. As shown in fig. 9F, the exemplary WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad/indicator 128, non-removable memory 130, removable memory 132, a power source 134, a Global Positioning System (GPS) chipset 136, and/or other peripheral devices 138. It should be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements. In addition, base stations 114a and 114B and/or nodes that base stations 114a and 114B may represent, such as, but not limited to, transceiver stations (BTSs), node bs, site controllers, access Points (APs), home node bs, evolved home node bs (enodebs), home evolved node bs (henbs), home evolved node B gateways, next generation node bs (gNode-B), proxy nodes, and the like, may include some or all of the elements depicted in fig. 9F and described herein.

The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, application Specific Integrated Circuits (ASICs), field Programmable Gate Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), a state machine, or the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120, which may be coupled to a transmit/receive element 122. Although fig. 9F depicts the processor 118 and the transceiver 120 as separate components, it should be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

The transmit/receive element 122 of a UE may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a of fig. 9A) over air interfaces 115/116/117, or to transmit signals to or receive signals from another UE over air interfaces 115d/116d/117 d. For example, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. The transmit/receive element 122 may be an emitter/detector configured to emit and/or receive, for example, IR signals, UV signals, or visible light signals. The transmit/receive element 122 may be configured to transmit and receive both RF signals and optical signals. It should be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals or wired signals.

Further, although the transmit/receive element 122 is depicted as a single element in fig. 9F, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Accordingly, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interfaces 115/116/117.

The transceiver 120 may be configured to modulate signals to be transmitted by the transmit/receive element 122 and demodulate signals received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs (e.g., NR and IEEE 802.11 or NR and E-UTRA) or with the same RAT via multiple beams to different RRH, TRP, RSU or nodes.

The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker/microphone 124, a keypad 126, and/or a display/touchpad/indicator 128 (e.g., a Liquid Crystal Display (LCD) display unit or an Organic Light Emitting Diode (OLED) display unit), the processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad/indicator 128.

The processor 118 may receive power from the power source 134 and may be configured to distribute and/or control power to other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries, solar cells, fuel cells, and the like.

The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114 b) over the air interface 115/116/117 and/or determine its location based on the timing of signals received from two or more nearby base stations. It should be appreciated that the WTRU 102 may obtain the location information by any suitable location determination method.

The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software modules and/or hardware modules that provide additional features, functionality, and/or wired or wireless connections. The peripheral device 138 may include various sensors, such as accelerometers, biometrics (e.g., fingerprint) sensor, electronic compass, satellite transceiver, digital camera (for photo or video), universal Serial Bus (USB) port or other interconnect interface, vibration device, television transceiver, hands-free headset,Modules, frequency Modulation (FM) radio units, digital music players, media players, video game player modules, internet browsers, and the like.

The WTRU 102 may be included in other apparatuses or devices such as sensors, consumer electronics, wearable devices (such as smart watches or smart clothing), medical or electronic health devices, robots, industrial equipment, drones, vehicles (such as automobiles, trucks, trains, or planes). The WTRU 102 may connect to other components, modules, or systems of such apparatuses or devices via one or more interconnect interfaces, such as an interconnect interface that may include one of the peripherals 138.

Fig. 9G is a block diagram of an exemplary computing system 90 in which one or more devices of the communication networks shown in fig. 9A, 9C, 9D, and 9E, such as some nodes or functional entities in RANs 103/104/105, core networks 106/107/109, PSTN 108, internet 110, other networks 112, or network services 113, may be embodied. The computing system 90 may comprise a computer or server and may be controlled primarily by computer readable instructions, which may be in the form of software, wherever or by whatever means such software is stored or accessed. Such computer readable instructions may be executed within processor 91 to cause computing system 90 to operate. Processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, application Specific Integrated Circuits (ASICs), field Programmable Gate Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), a state machine, or the like. Processor 91 may perform signal encoding, data processing, power control, input/output processing, and/or any other functionality that enables computing system 90 to operate in a communication network. Coprocessor 81 is an optional processor, different from main processor 91, that may perform additional functions or assist processor 91. Processor 91 and/or coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

In operation, processor 91 fetches instructions, decodes and executes instructions, and transfers information to and from other resources via the main data transfer path (system bus 80) of the computing system. Such a system bus connects the components in computing system 90 and defines a medium for data exchange. The system bus 80 typically includes data lines for transmitting data, address lines for transmitting addresses, and control lines for transmitting interrupts and for operating the system bus. An example of such a system bus 80 is a PCI (peripheral component interconnect) bus.

The memory coupled to the system bus 80 includes Random Access Memory (RAM) 82 and Read Only Memory (ROM) 93. Such memories include circuitry that allows information to be stored and retrieved. ROM 93 typically contains stored data that cannot be easily modified. The data stored in RAM 82 may be read or changed by processor 91 or other hardware device. Access to RAM 82 and/or ROM 93 may be controlled by memory controller 92. The memory controller 92 may provide address translation functionality that translates virtual addresses into physical addresses as instructions are executed. The memory controller 92 may also provide memory protection functions that isolate processes within the system and isolate system processes from user processes. Thus, a program running in the first mode may only access memory mapped by its own process virtual address space; unless memory sharing between processes has been set, it cannot access memory within the virtual address space of another process.

In addition, the computing system 90 may contain a peripheral controller 83 responsible for delivering instructions from the processor 91 to peripheral devices, such as a printer 94, keyboard 84, mouse 95, and disk drive 85.

The display 86, controlled by the display controller 96, is used to display visual output generated by the computing system 90. Such visual outputs may include text, graphics, animated graphics, and video. The visual output can be provided in the form of a Graphical User Interface (GUI). The display 86 may be implemented with a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch pad. The display controller 96 includes the electronics necessary to generate the video signals that are sent to the display 86.

Further, the computing system 90 may contain communications circuitry such as, for example, a wireless or wired network adapter 97 that may be used to connect the computing system 90 to external communications networks or devices such as the RANs 103/104/105, core networks 106/107/109, PSTN 108, internet 110, WTRU 102, or other networks 112 of fig. 9A, 9B, 9C, 9D, and 9E to enable the computing system 90 to communicate with other nodes or functional entities of these networks. Communication circuitry alone or in combination with processor 91 may be used to perform the transmit and receive steps of certain apparatus, nodes or functional entities described herein.

It will be appreciated that any or all of the apparatus, systems, methods, and processes described herein can be embodied in the form of computer-executable instructions (e.g., program code) stored on a computer-readable storage medium, which when executed by a processor (such as processor 118 or 91), cause the processor to perform and/or implement the systems, methods, and processes described herein. In particular, any of the steps, operations, or functions described herein may be implemented in the form of such computer-executable instructions executed on a processor of a computing system or device configured for wireless and/or wired network communications. Computer-readable storage media include volatile and nonvolatile, removable and non-removable media implemented in any non-transitory (e.g., tangible or physical) method or technology for storage of information, but such computer-readable storage media do not include signals. Computer-readable storage media includes, but is not limited to RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible or physical medium which can be used to store the desired information and which can be accessed by a computing system.

Claims

1. A wireless transmit/receive unit (WTRU) comprising a transceiver and one or more processors, the WTRU configured to:

Receiving a Data Network Name (DNN) replacement rule comprising a traffic descriptor and a routing descriptor (RSD), wherein the traffic descriptor comprises a first DNN and the RSD comprises a second DNN;

Receiving a third DNN from the application;

Determining that the third DNN matches the first DNN associated with the traffic descriptor;

determining to associate traffic from the application with a Protocol Data Unit (PDU) session associated with the second DNN based on the RSD; and

The PDU session is used to route the traffic from the application.

2. The WTRU of claim 1, wherein determining to associate the traffic from the application with the PDU session comprises sending a PDU setup request including the second DNN.

3. The WTRU of claim 2, wherein the PDU session establishment request includes an indication that the second DNN is an alternate DNN.

4. The WTRU of claim 1 wherein the PDU session is an existing PDU session.

5. The WTRU of claim 1, wherein the WTRU is configured to receive a user equipment routing policy (URSP) rule that includes the DNN replacement rule.

6. The WTRU of claim 5 wherein the URSP rule is received in a non-access stratum (NAS) message.

7. The WTRU of claim 1, wherein the WTRU is configured to send an indication that the WTRU is configured to receive the DNN replacement rule, and the DNN replacement rule is received in response to the indication.

8. The WTRU of claim 7, wherein the indication is sent in a registration request.

9. The WTRU of claim 1, wherein the DNN substitution rule is received in a UE configuration update message.

10. The WTRU of claim 1, wherein determining that the third DNN matches the first DNN comprises determining that the third DNN is equal to the first DNN.

11. A method performed by a wireless transmit/receive unit (WTRU), the method comprising:

Receiving a third DNN from the application;

The PDU session is used to route the traffic from the application.

12. The method of claim 11, wherein determining to associate the traffic from the application with the PDU session comprises sending a PDU setup request including the second DNN.

13. The method of claim 12, wherein the PDU session establishment request includes an indication that the second DNN is a replacement DNN.

14. The method of claim 11, wherein the PDU session is an existing PDU session.

15. The method of claim 11 wherein the WTRU is configured to receive a user equipment routing policy (URSP) rule that includes the DNN replacement rule.

16. The method of claim 15, wherein the URSP rule is received in a non-access stratum (NAS) message.

17. The method of claim 11 wherein the WTRU is configured to send an indication that the WTRU is configured to receive the DNN replacement rule, and the DNN replacement rule is received in response to the indication.

18. The method of claim 17, wherein the indication is sent in a registration request.

19. The method of claim 11, wherein the DNN substitution rules are received in a UE configuration update message.

20. The method of claim 11, wherein determining that the third DNN matches the first DNN comprises determining that the third DNN is equal to the first DNN.