Proximity service path selection and switching
By controlling the policy of the 5G core network, the UE is guided to switch between the Uu and PC5 interfaces, which solves the efficiency problem of UE path selection and handover in the 5G system and realizes efficient direct communication and communication support outside the coverage area.
Patent Information
- Application Number
- CN202180036825.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2020-05-21
- Filing Date
- 2021-05-21
- Publication Date
- 2026-01-27
- Estimated Expiration
- 2041-05-21
AI Technical Summary
Existing 5G systems fail to effectively support user equipment (UE) in direct path selection and handover, resulting in wasted network resources and communication difficulties outside coverage areas.
The Application Function (AF) of the 5G core network initiates the Policy Control Function (PCF) to create a Nearby Service Path Selection and Handover (PSS) policy, which guides the UE to handover between the Uu and PC5 interfaces. Combined with the Direct Discovery Name Management Function (DDNMF) and network-assisted path selection, direct communication between UEs is achieved.
It improves the efficiency of direct communication between UEs, saves network resources, supports public safety communication outside the coverage area, and meets the quality and latency requirements of different services.
Smart Images

Figure CN115669009B_ABST
Abstract
Description
Background Technology
[0001] Proximity Service (ProSe) comprises two features: (1) network-assisted discovery for user equipment (UEs) that wish to communicate with each other and are close to each other; and (2) facilitation of direct communication between UEs, both with and without input from the network. Direct communication means establishing a radio connection between UEs without transmitting information via the network. This saves network resources and enables public safety communication in areas outside network coverage.
[0002] In 5G New Radio (NR), ProSe is expected to be a crucial system-wide enabler supporting a wide range of applications and services in both the commercial and public safety domains. For example, 3GPP TR 22.842 identifies emerging Network Control Interactive Services (NCIS) that share certain common requirements with public safety services and applications. For any form of service, path selection is necessary to support throughput, latency, reliability requirements, or other service requirements. Summary of the Invention
[0003] Some exemplary embodiments include a computer-readable storage medium comprising a set of instructions that, when executed by a processor, cause the processor to perform operations. These operations include: determining that a triggering event has occurred, wherein the triggering event is based on a set of Proximity Service (ProSe) Path Selection and Handover (PSS) policies; transmitting an establishment or update request to the Direct Discovery Name Management (DDNMF) function of the 5G core network; receiving a UE-specific policy based on the set of ProSe PSS policies; and handing over from one of the PC5 interface or the Uu interface to the other of the PC5 interface or the Uu interface.
[0004] Other exemplary embodiments relate to a user equipment (UE) having a transceiver and a processor. The transceiver is configured to connect to a next-generation node (gNB) and another UE. The processor is configured to: determine that a triggering event has occurred, wherein the triggering event is based on a set of Proximity Service (ProSe) Path Selection and Handover (PSS) policies; transmit an establishment or update request to the Direct Discovery Name Management Function (DDNMF) of the 5G core network; receive UE-specific policies based on the set of ProSe PSS policies; and switch from one of a PC5 interface used for connecting to the other UE or a Uu interface used for connecting to the gNB to the other of the PC5 interface or the Uu interface.
[0005] Other exemplary embodiments relate to an integrated circuit configured for use in a user equipment (UE). The integrated circuit includes: circuitry configured to determine that a triggering event has occurred, wherein the triggering event is based on a set of Proximity Service (ProSe) Path Selection and Handover (PSS) policies; circuitry configured to transmit an establishment or update request to the Direct Discovery Name Management Function (DDNMF) of the 5G core network; circuitry configured to receive UE-specific policies based on the set of ProSe PSS policies; and circuitry configured to switch from one of a PC5 interface for connecting to another UE or a Uu interface for connecting to a next-generation node B (gNB) to the other of the PC5 interface and the Uu interface. Attached Figure Description
[0006] Figure 1 Exemplary network arrangements according to various exemplary implementations are shown.
[0007] Figure 2 Exemplary UEs according to various exemplary implementations are shown.
[0008] Figure 3A and Figure 3B An exemplary network architecture for proximity services is shown according to various exemplary implementations.
[0009] Figure 4 The diagram illustrates a signaling diagram of path selection and switching policies created by a policy control function (PCF) initiated by an application function (AF) according to various exemplary implementations.
[0010] Figure 5 Signaling diagrams for network-assisted path selection and handover according to various exemplary embodiments are shown.
[0011] Figure 6 Signaling diagrams for application-assisted path selection and switching according to various exemplary implementations are shown.
[0012] Figure 7 Signaling diagrams for policy configuration updates requested by a UE according to various exemplary embodiments are shown.
[0013] Figure 8 Signaling diagrams based on Network Data Analysis Function (NWDAF) for path selection and handover analysis and prediction are shown according to various exemplary implementations. Detailed Implementation
[0014] The exemplary embodiments can be further understood with reference to the following description and related figures, wherein similar elements have the same reference numerals. The exemplary embodiments relate to Proximity Services (ProSe), and more specifically, to the selection and switching of communication paths.
[0015] The exemplary embodiments are described with respect to the UE. However, the use of the UE is for illustrative purposes only. The exemplary embodiments can be used with any electronic component capable of establishing a connection to a network and configured with hardware, software, and / or firmware for exchanging information and data with that network. Therefore, the UE described herein is used to represent any electronic component.
[0016] Exemplary embodiments are also described with reference to networks including 5G NR Radio Access Technology (RAT). However, the reference to 5G NR networks is provided for illustrative purposes only. Exemplary embodiments can be used with any network implementing ProSe and equivalent technologies. Therefore, a 5G NR network as described herein can represent any network including ProSe functionality.
[0017] To improve support for ProSe functionality, the UE can select an appropriate direct communication path (or interface) based on a pre-defined policy, which can be configured by the network operator or assisted by the network when available. Currently, the UE Route Selection Policy (URSP) rules do not identify which services(s) apply to a specific UE. Therefore, the UE is left to determine which services are applicable for itself. An unresolved issue regarding ProSe is how 5G systems (5GS) can support direct path selection and handover performed by the UE.
[0018] According to an exemplary implementation, the Application Function (AF) of the 5G core network can initiate the creation of ProSe Path Selection and Handover (PSS) policies by the Policy Control Function (PCF), which also belongs to the 5G core network. These policies guide the UE in selecting and handing over communication paths (Uu and / or PC5). In some implementations, the network may trigger or initiate a handover between the Uu interface (the Universal Mobile Telecommunications System air interface between the UE and the radio access network) and the PC5 interface (the UE-to-UE interface) due to satisfaction of one or more PSS policies or due to an application-triggered event. In some implementations, the UE may trigger or initiate a handover between Uu and PC5 due to satisfaction of one or more PSS policies.
[0019] Figure 1An exemplary network arrangement 100 according to various exemplary embodiments is illustrated. The exemplary network arrangement 100 includes a first UE 110A, a second UE 110B, and a third UE 110C (collectively, UE 110). It should be noted that any number of UEs can be used in the network arrangement 100. Those skilled in the art will understand that UE 110 can be any type of electronic component configured to communicate via a network, such as a mobile phone, tablet, desktop computer, smartphone, phablet, embedded device, wearable device, Internet of Things (IoT) device, etc. It should also be understood that a practical network arrangement can include any number of UEs used by any number of users. Therefore, for illustrative purposes, only an example with a single UE 110 is provided.
[0020] UE 110 can be configured to communicate with one or more networks. In the example of network configuration 100, the networks with which UE 110 can wirelessly communicate are 5G New Radio (NR) Radio Access Network (5G NR-RAN) 120, LTE Radio Access Network (LTE-RAN) 122, and Wireless Local Access Network (WLAN) 124. However, it should be understood that UE 110 can also communicate with other types of networks, and UE 110 can also communicate with networks via wired connections. Therefore, UE 110 may include a 5G NR chipset communicating with 5G NR-RAN 120, an LTE chipset communicating with LTE-RAN 122, and an ISM chipset communicating with WLAN 124.
[0021] 5G NR-RAN 120 and LTE-RAN 122 can be parts of cellular networks that can be deployed by cellular providers (e.g., Verizon, AT&T, Sprint, T-Mobile, etc.). These networks 120, 122 can include, for example, cells or base stations (NodeB, eNodeB, HeNB, eNBS, gNB, gNodeB, macrocell base stations, microcell base stations, small cell base stations, femtocell base stations, etc.) configured to send and receive traffic from UEs equipped with appropriate cellular chipsets. WLAN 124 can include any type of wireless local area network (WiFi, hotspot, IEEE 802.11x network, etc.).
[0022] UE 110 can connect to 5G NR-RAN 120 via gNB 120A. gNB 120A can be configured with the necessary hardware (e.g., antenna array), software, and / or firmware to perform massive MIMO functionality. Massive MIMO can refer to a base station configured to generate multiple beams for multiple UEs. During operation, UE 110 can be within range of multiple gNBs. Therefore, simultaneously or alternatively, UE 110 can also connect to 5G NR-RAN 120 via gNB 120B. Reference to the two gNBs 120A and 120B is for illustrative purposes only. Exemplary implementations can be applied to any suitable number of gNBs. Additionally, UE 110 can communicate with eNB 122A of LTE-RAN 122 to transmit and receive control information for downlink and / or uplink synchronization relative to the 5G NR-RAN 120 connection.
[0023] Those skilled in the art will understand that any association process for UE 110 to connect to 5G NR RAN 120 can be performed. For example, as discussed above, 5G NR RAN 120 can be associated with a specific cellular provider, where UE 110 and / or its user have protocol and credential information (e.g., stored on a SIM card). Upon detecting the presence of 5G NR RAN 120, UE 110 can transmit the corresponding credential information to associate with 5G NR RAN 120. More specifically, UE 110 can be associated with a specific base station (e.g., gNB 120A of 5G NR RAN 120).
[0024] In addition to networks 120 and 122, network deployment 100 also includes a cellular core network 130. The cellular core network 130 can be viewed as an interconnected collection of components that manage the operation and traffic of the cellular network. In this example, these components include Session Management Function (SMF) 131, Access and Mobility Management Function (AMF) 132, User Plane Function (UPF) 133, Policy Control Function (PCF) 134, Application Function (AF) 135, Direct Discovery Name Management Function (DDNMF) 136, Network Exposure Function (NEF) 137, Unified Data Management (UDM) 138, and Unified Data Repository (UDR) 139. However, a real cellular core network may include various other components performing any of a variety of different functions.
[0025] SMF 131 performs operations related to: Session Management (SM), UE IP address allocation and management (including optional authorization), selection and control of user plane functions; configuring traffic guidance at UPF 133 to route traffic to appropriate destinations, terminating interfaces for policy control functions, controlling policy enforcement and a portion of Quality of Service (QoS), downlink data notification; initiating access network-specific SM information sent to 5G NR RAN 120 via AMF 132; and determining the Session and Service Continuity (SSC) mode of the session. SM may refer to the management of PDU sessions. A PDU session may refer to the PDU connectivity service that provides or enables PDU exchange between UE 110 and cellular core network 130. A PDU session may be established upon request by UE 110. The reference to a single SMF 131 is for illustrative purposes only; actual network deployments may include any appropriate number of SMFs, as discussed below.
[0026] AMF 132 performs operations related to mobility management, such as, but not limited to, paging between UE 110 and cellular core network 130, non-access stratum (NAS) management, and registration process management. The reference to a single AMF 132 is for illustrative purposes only; actual network deployments may include any appropriate number of AMFs.
[0027] UPF 133 performs operations related to intra- and inter-RAT mobility, external PDU session points interconnected with the cellular core network 130, and branch points supporting multihomed PDU sessions. UPF 133 can also perform packet routing and forwarding, packet inspection, enforcement of policy rules in the user plane portion, lawful packet interception (UP collection), traffic usage reporting, QoS processing on the user plane (e.g., packet filtering, gating, UL / DL rate enforcement), uplink traffic authentication (e.g., Service Data Flow (SDF) to QoS flow mapping), transport level packet marking in uplink and downlink, and downlink packet buffering and downlink data notification triggering. The reference to a single UPF 133 is for illustrative purposes only; actual network deployments may include any appropriate number of UPFs.
[0028] PCF 134 performs operations related to the control plane, such as, but not limited to, managing policy rules for control plane functions, including network slicing, roaming, and mobility management. The reference to a single PCF 134 is for illustrative purposes only; actual network deployments may include any appropriate number of PCFs.
[0029] AF 135 (also referred to herein as “ProSe AF 135”) performs operations related to the influence of applications on traffic routing, access to the Network Cloud Engine (NCE), and interaction with the policy framework for policy control. The NCE can be a mechanism that allows information exchange between the cellular core network 130 and AF 135, which can be used in edge computing implementations. In such implementations, network operators and third-party services can be hosted near the attached access point of UE 110 to achieve efficient service delivery through reduced end-to-end latency and load on the transport network. For edge computing implementations, the cellular core network 130 can select a UPF 133 close to UE 110 and perform traffic routing from the UPF 133 to the network. This can be based on UE subscription data, UE location, and information provided by AF 135. Thus, AF 135 can influence UPF (re)selection and traffic routing. The reference to a single AF 135 is merely illustrative; actual network deployments may include any appropriate number of AFs. In some implementations, the AF 135 can also act as a ProSe application server.
[0030] DDNMF 136 can be used to handle the mapping of ProSe application IDs for ProSe direct discovery. In some implementations, DDNMF 136 may be a standalone function within the core network 130. In some implementations, DDNMF 136 may be part of an application server.
[0031] The NEF 137 provides means for securely exposing services and capabilities provided by 3GPP network functions to third-party application functions (e.g., AF135), edge computing, or fog computing systems. In some implementations, the NEF 137 can authenticate, authorize, and / or restrict AFs. The NEF 137 can also translate information exchanged with AF 135 and information exchanged with other network functions. For example, the NEF 137 can act as a converter between AF service identifiers and internal 5GC information. The NEF 137 can also receive information from other network functions (NFs) based on their exposure capabilities. This information can be stored as structured data at the NEF 137 or stored at a data storage device using a standardized interface. The stored information can then be re-exposed by the NEF 137 to other AFs and / or used for other purposes, such as analysis.
[0032] UDM 138 can process subscription-related information to support network entities in handling communication sessions and can store UE 110's subscription data. For example, subscription data can be transferred between UDM 138 and AMF 132. UDM may include a front-end (FE) responsible for handling credentials, location management, subscription management, etc. Several different front-ends can provide services to the same user in different transactions. UDM-FE accesses subscription information stored in UDR 139 and performs authentication credential processing, user identification processing, access authorization, registration / mobility management, and subscription management.
[0033] UDR 139 can store subscription data and policy data of UDM 138 and PCF 134, and / or structured data for exposure of NEF 137, as well as application data (including Packet Flow Description (PFD) for application detection and application request information of multiple UEs 110). The Nudr-based service interface can be presented by UDR 221 to allow UDM 138, PCF 426, and NEF 423 to access specific sets of the stored data, and to receive notifications of reading, updating (e.g., adding, modifying, deleting), and subscribing to relevant data changes in UDR 139.
[0034] Figure 2 An exemplary UE 110 according to various exemplary embodiments is shown. Reference will be made to... Figure 1 The network layout 100 is used to describe UE 110. UE 110 can represent any electronic device and may include processor 205, memory layout 210, display device 215, input / output (I / O) device 220, transceiver 225, and other components 230. Other components 230 may include, for example, audio input devices, audio output devices, batteries providing a limited power source, data acquisition devices, ports for electrically connecting UE 110 to other electronic devices, one or more antenna panels, etc. For example, UE 110 may be coupled to industrial equipment via one or more ports.
[0035] Processor 205 can be configured to execute multiple engines of UE 110. For example, an engine may include ProSe management engine 235. ProSe management engine 235 can perform various ProSe-related operations, such as path selection, path switching, and policy update requests.
[0036] The engine described above, as an application (e.g., a program) executed by processor 205, is merely exemplary. The functionality associated with the engine may also be represented as a separate, integrated component of UE 110, or as a modular component coupled to UE 110, such as an integrated circuit with or without firmware. For example, the integrated circuit may include input circuitry for receiving signals and processing circuitry for processing signals and other information. The engine may also be embodied as a single application or multiple separate applications. Furthermore, in some UEs, the functionality described for processor 205 is distributed among two or more processors, such as a baseband processor and an application processor. Exemplary implementations can be implemented according to any of these or other configurations of the UE.
[0037] Memory arrangement 210 may be a hardware component configured to store data related to operations performed by UE 110. Display device 215 may be a hardware component configured to display data to a user, while I / O device 220 may be a hardware component enabling user input. Display device 215 and I / O device 220 may be separate components or may be integrated together (such as a touchscreen). Transceiver 225 may be a hardware component configured to establish connections with 5G NR-RAN 120, LTE-RAN 122, WLAN 124, etc. Therefore, transceiver 225 may operate on multiple different frequencies or channels (e.g., a continuous set of frequencies).
[0038] Figure 3A and Figure 3B An exemplary network architecture for proximity services is shown according to various exemplary implementations. Figure 3A and Figure 3B The network architecture shown is basically similar to Figure 1 The network architecture is shown, but more details related to proximity services are illustrated. As described above regarding core network 130, Figure 3A and Figure 3B The network functions described above. Furthermore, the network has a data network name (DNN) 302 (302A or 302B) including AF 135. Figure 3A network architecture and Figure 3B The difference between the network architectures is that DDNMF 136 in Figure 3A It is an independent network function on the core network, and in Figure 3B It is placed alongside AF 135 on DNN 302.
[0039] Figure 3A and Figure 3BThe diagram also shows UE 110, with each UE running ProSe application 304. In some implementations, a first UE 110A may be connected to RAN 120 via a Uu path / interface, while a second UE 110B and a third UE 110C may be connected to the first UE 110A via a PC5 path / interface to establish their respective connections with RAN 120.
[0040] DDNMF 136 is a standalone function. Figure 3A In the implementation scheme, DDNMF interacts with the ProSe application server (AF 135) via the PC2 interface and with the UE 110 via the PC3 interface. As defined in 3GPP TS 23.303, PC3 is the interface between the UE and the ProSe function. PC3 "is used to authorize ProSe direct discovery and network-level ProSe discovery requests, and to execute the allocation of ProSe application codes / ProSe restriction codes corresponding to the ProSe application identifier used for ProSe direct discovery. It is used to limit the authorization policy based on the PLMN for ProSe direct discovery (for both public and non-public safety) and communication between the UE and the ProSe function (for public safety only)." It can be used with DNN 306A, which has its own third-party application. Figure 3A ProSe's third-party application service providers (as shown in the example) have multiple relationships.
[0041] In this context, DDNMF 136 is co-located with AF 135 on DNN 302B. Figure 3B In the implementation scheme, the PC2 interface is internally supported, as well as the PC3 interface of DDNMF 136 to UE 110B and the PC1 interface between the application server (part of DNN) and UE 110. If DDNMF 136 needs to utilize services provided by other network functions (described above), then DDNMF is used as a network function.
[0042] As mentioned above, the current UE route selection policy (URSP) rules do not identify which services(s) apply to a specific UE. Therefore, the UE is allowed to determine which services are applicable for itself. However, for ProSe rules / policies, the policy field "00000100ProSe" can be used. ProSe rules can be pushed to UEs that support the ProSe feature. The 5G core network 130 will provide ProSe rules to UEs that set the ProSe Information Element (IE) to 1 in the registration request. Table 1 shows a list of ProSe route selection and handover (PSS) policies / rules that can be created by the PCF (e.g., PCF 134) in response to a request from AF 135.
[0043]
[0044]
[0045] Table 1: PSS Strategy
[0046] It should be noted that all or a subset of these strategies are applicable to a given ProSe application session. Although most of the strategies in Table 1 are self-evident, some of these strategies will now be briefly described to provide clarity and to explain their impact on the ProSe session and their relationship to the session.
[0047] The session validity timer policy specifies the duration for which a UE can maintain a PC5 session with another UE (or UE to network repeater). The keep-alive timer policy specifies a time period after which the UE will need to send a keep-alive activity transmission to the DDNMF node via the PC3 interface or another UE (UE to network repeater) to let the NW know that the UE is still using PC5 to connect to another UE. In other words, the UE is informing the NW that it is still an active UE and should not be ignored by the NW. The fallback timer policy limits the number of requests a UE can send on a single interface. In the case of two UEs close to the maximum distance where ProSe can function, if one of these UEs is idle, there may not be much impact. However, if data is exchanged between these two UEs, the Quality of Service (QoS) may be negatively affected. Therefore, a UE connected to another UE (repeater) via PC5 will switch to Uu to connect to the RAN. However, at some point, the UE will attempt to switch back to proximity mode (PC5). To avoid this back-and-forth switching, the fallback timer limits the number of requests a UE can make on the same interface (PC5 or Uu). The policy verification policy imposes a time constraint on the policy's validity. After this period expires, the UE may need to switch between interfaces or request a new policy / policy update.
[0048] The authorized PLMN policy specifies which Public Land Mobile Network (PLMN) and / or Independent Non-Public Network (SNPN) these ProSe PSS policies are valid in. Support Area policies in the AMF restrict the UE's ability to use ProSe to a specific RAN area, thereby preventing the UE from using ProSe in another AMF or using other policies in another AMF and PCF. Geographic Validity policies define the geographic areas within which the UE can use neighboring services, and may include a list of latitude and longitude. The PSS policies in Table 1 relate to this defined area. Signal Threshold policies define a threshold above which the UE can switch to PC5 if the signal strength on the PCF is above the threshold, or switch to Uu if the Uu signal strength is above the threshold. Frequency / Geographic Area policies define the frequencies (licensed or unlicensed spectrum) that will be used for ProSe communication in a given geographic area. This must be provided to the UE as a criterion for selecting which frequencies the UE will use for the PC5 and Uu interfaces. Seamless Offload policies specify whether seamless offload is supported or not. For example, if the NW is broadcasting and some UEs do not have good connectivity to the RAN, one UE can act as a repeater for other UEs. However, when other UEs move away from the repeater or move into the enhanced RAN coverage area, it is necessary to know whether buffering is required.
[0049] The subscription type policy identifies whether the communication is multicast or emergency, and whether ProSe communication follows Model A, Model B, or both. Model A is a declaration of the UE's presence to other devices. In Model B, the UE already knows which devices are present and inquires if any of those devices want to connect. The subscription type policy specifies which models the NW accepts. Multimedia Broadcast Multicast Service (MBMS) or Multicast Broadcast Service (MBS) can be used with ProSe, and / or emergency broadcast can be used with ProSe applications. Service identifier policies include multicast (only within a specified group), broadcast (to any listenable device), or unicast (UE to UE). Broadcasts can include commercial, public safety, or multicast applications.
[0050] Special service type policies identify whether an application is a special service type, such as, for example, an Ultra-Reliable Low-Latency Communication (URLLC) application or an Industrial Internet of Things (IIoT) application. Various special services can utilize ProSe. For example, in remote surgery, a doctor located far from the surgical site (e.g., a hospital) connects to the NW via URLLC. A UE at the surgical site also connects to the NW via URLLC, and any other device at the surgical site can connect to the UE via ProSe. This policy will inform those devices that the communication in this session is URLLC, and QoS will be defined similarly.
[0051] Group restriction policies restrict ProSe applications to specific groups by providing an application function ID (e.g., a specific application ID). AF 135 provides this information to PCF 134 so that these policies can be provided to UE 110. Authorization allows policies to grant authorization for one-to-one, one-to-many, or UE-to-relay communication. One-to-one includes ProSe communication and can be, for example, URLLC or other applications that help UEs outside coverage connect to the NW. One-to-many may include a UE connecting to multiple UEs to exchange information with each other (e.g., for playing games together). UE-to-relay allows a UE to act as a repeater for connecting other devices to the NW.
[0052] The repeater user plane (UP) policy provides the UE with Network Slice Selection Assistance Information (NSSAI) or the DNN to which the application will use. This policy can also define whether this dedicated network slice should be used for ProSe applications to connect to the NW. For example, if the UE is a repeater for another UE and the UE uses a specific network slice to connect to the NW, the policy will specify whether the UE should use the same network slice to connect other devices to the NW or whether the UE should use a different network slice or DNN to connect those devices to the NW. The policy also identifies which network slice the repeater should use for other devices (this is provided by the AF). Furthermore, once QoS and location criteria are met, the service criteria policy instructs the UE to access the pre-determined slice and / or DNN once the repeater is selected. Therefore, for the UE, this policy is largely an instruction.
[0053] Figure 4 Signaling diagrams of PCF-based path selection and handover policies initiated by the AF (from Table 1) according to various exemplary implementations are shown. It should be noted that multiple applications may use various different or the same information provided to the UE via these policies.
[0054] At 405, AF 135 initiates ProSe service-specific information configuration. In some implementations, this request may be triggered by the application server (AF 135), forwarded by DDNMF 136 via the PC2 interface, or received from UE 110 via the PC3 / PC1 interface (user plane (UP) interface) based on a triggering event. In some implementations, this may be due to UE registration and policy association. In some implementations, this may be due to the UE attempting to access certain ProSe applications or a particular ProSe application becoming necessary (e.g., repeaters, extended coverage, etc.). In some implementations, AF 135 initiates the request because the application server wants to start a session with UE 110 and inform UE 110 that it can use the services provided by the application server. Therefore, there may be multiple reasons / triggering events that cause AF to initiate ProSe service-specific information configuration at 405.
[0055] At 410, PCF 134 creates a policy based on the PSS policy discussed above with reference to Table 1 for this specific application instance and application ID. For example, policies for path selection and handover for NW-assisted services may involve coverage and range, QoS, time window, location within the NW, and / or UE location. For example, if a UE moves out of Uu coverage and the UE's ProSe discovery of the NW repeater (another UE) is successful, the UE may switch to the PC5 interface with the repeater to continue service. The range (distance) between the two UEs also affects the ability to utilize proximity services. QoS is forwarded from PCF 134 to UE 110 and RAN 120 for operation of the PC5 and Uu interfaces in the event of a UE handover between interfaces. If the QoS on PC5 is below a threshold, UE 110 may switch to the Uu interface if a better QoS is available on the Uu interface. Similarly, if proximity discovery has occurred and the PC5 interface provides reliable QoS, UE 110 may switch from the Uu interface to the PC5 interface.
[0056] PCF 134 can also provide a time window during which UE 110 can utilize the ProSe PC5 interface instead of the Uu interface. UE 110 can switch from PC5 to Uu after the specified time window has expired. Similarly, in the case of successful proximity discovery, UE 110 can initiate a handover from Uu to PC5 when the time has begun. A list of Tracking Areas (TAs) or Registered Areas (RAs) within a PLMN supporting ProSe functionality can be stored on PCF 134. If UE 110 moves out of the area defined in these lists, UE 110 should switch from the PC5 interface to the Uu interface and may also request a policy update from PCF 134. ProSe applications are also effective within a limited area defined by latitude and longitude coordinates. These policies can also instruct a UE operating on the PC5 interface to switch to the Uu interface if UE 110 moves further away from this area. However, UE 110 may later initiate another request for a policy update after the handover from PC5 to Uu.
[0057] At 415, the policy created by PCF 134 is forwarded to AMF 132 via the AMPolicyControlUpdate message (previously subscribed to by PCF). At 420, the ProSe service access management policy is forwarded to the UE for this specific application ID and session ID.
[0058] Figure 5 The diagram illustrates signaling diagrams for network-assisted path selection and switching according to various exemplary embodiments. At 505, a triggering event occurs for path switching or selection. In some embodiments, the triggering event at 505 may be an event that causes the AF 135 to initiate ProSe service-specific information configuration (as described above regarding...). Figure 4 The AF triggering event (described above) can be an unavailability of the PC1 link between UE 110 and the application server (AF 135) due to a UE mobility event. In some embodiments, the AF triggering event can be an application-requested (e.g., an application or a third-party provider) Multimedia Broadcast Service (MBS) session enabling the MBS repeater to broadcast content. In some embodiments, the AF triggering event can be an application-requested commercial broadcast, causing commercial broadcasts pushed to the UE acting as the repeater to also be pushed to all UEs served by the repeater. In some embodiments, the AF triggering event can be a policy / configuration update sent by a third-party public safety provider application server to the ProSe AF 135, enabling emergency broadcasts pushed to the UE acting as the repeater to also be pushed to all UEs served by the repeater.
[0059] In some implementations, the triggering event at 505 can be a UE-triggered event. In some implementations, if a PDU session has not yet been established with the ProSe AF 135, the UE 110 will establish a PDU session according to its UE configuration, such as using a specific NW slice or connecting to the ProSe AF 135 for that specific application session. In some implementations, the UE-triggered event may be due to the UE acting as a repeater being unable to discover the PC5 interface with a UE in Radio Resource Control (RRC) idle mode. This will trigger an RRC resume service event or an RRC connection establishment service event. In some implementations, the UE-triggered event may be due to a desire to switch an application session from Uu to PC5 based on proximity discovery. For example, if a first UE is exchanging data with a second UE via NW, and later, the first and second UEs are close to each other, a UE may want to switch from Uu to PC5.
[0060] In some implementations, the triggering event at 505 may be a UE-triggered ProSe policy configuration to AMF 132. In some implementations, this may be caused by the expiration of a validity timer indicated in the PSS policy, thereby causing UE 110 to trigger a request to switch to the Uu interface or request a new / updated policy. In some implementations, UE-triggered ProSe policy configuration may be caused by the unavailability of validity parameters, such as in the geographic area where the UE is located, or by some other anomaly that would cause the UE to request a policy update.
[0061] In some implementations, the triggering event at 505 may be a PCF-triggered policy configuration update. This could be due to the UE not satisfying one or more PSS policies in the PSS policies created by PCF 134. In some implementations, this is caused by UE mobility events such as, for example, the UE moving from one PLMN to another, which occurs when the UE uses a UE policy association modification procedure initiated by the AMF. In some implementations, a PCF-triggered policy configuration update may occur when there is a subscription change in the list of PLMNs in which the UE is authorized to perform ProSe operations via PC5, and this subscription change is implemented using a UE policy association modification procedure initiated by PCF 134. In some implementations, a PCF-triggered policy configuration update may occur when there is a change in service-specific parameter configuration.
[0062] return Figure 5At point 510, the UE / relay unit 110 uses the PC3 interface to send a deregistration request or group communication update to the DDNMF 136. It should be noted that this request may or may not be generated depending on which triggering event occurs at point 505. For example, if the triggering event is an AF triggering event, the UE request may be skipped. It should also be noted that this request may depend on the number of UEs and the existing UE communication.
[0063] At point 515, DDNMF 136 generates a session update request and forwards this request to AF 135 using the PC2 interface. In some implementations, this request includes the application ID, user ID, session ID, and other ProSe session parameters. Whether DDNMF is a standalone function or co-located with AF 135, the connectivity between DDNMF 136 and AF 135 remains the same.
[0064] At point 520, AF 135 invokes a traffic impact request for the application ID and session ID based on the trigger event type at point 505 and the node (UE or AF) where the trigger event occurred. The request type is ProSe discovery, handover, or policy change. Therefore, AF 135 initiates traffic impact for path handover and policy change. At point 525, NEF 137 forwards the request as a policy authorization creation / modification / deletion to the relevant PCF 134 based on the nature of the request received from AF 135 and the handover type (Uu to PC5 or PC5 to Uu).
[0065] At point 530, PCF 134 generates / modifies UE-specific PSS policy updates. Policies can be updated based on the PSS policies in Table 1. At point 535, PCF 134 uses SM policy control messages to forward policy updates with PSS updates, application types, and other session information to SMF 131 for further processing of the PDU session. At point 540, the N4 session is modified at the UPF level as policies change, and UP tunnels are created, modified, or torn down based on request type, trigger event type, or application type.
[0066] At 545, the PDU session update is forwarded from SMF 131 to AMF 132 for further processing of the request. At 550, AMF 132 sends an N2 update message to RAN 120 for updating policies at the RAN level and forwards these policies to the specific UE 110.
[0067] At 555, depending on the UE's state and existing connections, RAN 120 can send a paging request in the area where UE 110 was previously located / is currently located. If UE 110 is idle or using PC5, UE 110 will need to be paged to connect to RAN 120 via Uu. If UE 110 is using Uu and wants to switch to PC5, RAN 120 will initiate an RRC reconfiguration. At 560, according to policy, state, and triggering events, a handover and selection of the interface (PC5 or Uu) is now performed at the UE / relay level, and a discovery request can be initiated at this step. However, if UE 110 is already using the PC5 interface and is switching to the Uu interface at 560, an RRC reconfiguration request (instead of a discovery request) can be initiated.
[0068] Figure 6 Signaling diagrams for application-assisted path selection and handover according to various exemplary embodiments are shown. First, it should be noted that if... Figure 6 If the content provider 602 shown is outside the 5G NW domain, then this signaling diagram will terminate at ProSe AF 135. However, in this discussion, it is assumed that the content provider 602 is within the 5G NW domain.
[0069] At 605, PC1 link monitoring is active between UE 110 and the application server (AF 135) or content provider 602. At 610, UE 110 is in RRC idle state. However, the PC5 link can be active between this UE 110 and the repeater (another UE). At 615, conditions for a triggering event related to a handover from PC5 to the Uu unicast link or vice versa can be met at the application server (AF 135) or content provider 602. At 620, AF 135 uses the PDU session forwarding request type in UP for downlink data of path handover and other content delivery. It should be noted that this request can be a unicast operation performed via Uu or a repeater operation implemented via a handover from Uu to PC5. At 625, this request is forwarded from UPF 133 to SMF 131 as an N4 message for session update.
[0070] At 630, the NW triggers a service request to page UE 110 for unicast delivery. The service request requests the UE to switch from PC5 to Uu, depending on whether the UE is unreachable or not performing link monitoring due to application state. At this time, the NW may trigger a service request or query UE 110 to request UE 110 to switch interfaces to receive data destined for UE 110 from content provider 602. In some implementations, the NW requests UE 110 to remain on PC5 but begins sending link monitoring requests. In some implementations, the NW requests UE 110 to use both PC5 and Uu simultaneously, although UE 110 selects one interface based on UE policy. In some implementations, the NW may request the UE to switch to Uu because data from content provider 602 can be transmitted via RAN 120.
[0071] At 635, an UP path handover is updated between UE 110 and the application server or content provider after the delivery link is established. At 640, UE 110 performs a path handover based on the UE's preferences (based on the PSS policy).
[0072] Figure 7 Signaling diagrams for policy configuration updates requested by a UE according to various exemplary embodiments are shown.
[0073] At 705, a UE trigger event occurs. The trigger event can be any PSS policy based on the PSS policies in Table 1 or any other policy triggered at UE 110, such as the UE trigger event discussed above. In some implementations, the UE trigger event can be as simple as initiating an application. At 710, the UE sends a policy configuration request to AMF 132, which includes a UE policy container (ProSe PSS Policy Configuration Request).
[0074] At 715, AMF 132 sends an update request (Npcf_UEPolicyControl_Update) to PCF 134, which includes the UE policy container received from UE 110 at 710. At 720, the UE policy delivery / update procedure defined in 3GPP TS 23.502 Part 4.2.4.3 is triggered. PCF 134 can determine whether a new policy is to be used. If PCF 134 determines that no new UE policy update exists for this session, ProSe is not available for the UE to use for this application, and UE 110 uses the Uu interface to connect to NW. However, if PCF 134 determines that a new policy exists, it can update the UE at 720.
[0075] Figure 8Signaling diagrams illustrating path selection and handover analysis and prediction based on the Network Data Analysis Function (NWDAF) according to various exemplary embodiments are shown. At 805, AF 135 may subscribe to NWDAF 802 for analysis and prediction requests to provide details that can help generate effective triggering events and policies for the corresponding UE. That is, AF 135 requests NWDAF 802 to provide analysis based on specific functions, such as, for example, enhanced coverage via repeaters, congestion mitigation, and application-specific data (e.g., which applications require or do not require ProSe). In some embodiments, this subscription request may include application type, application ID, and supported interfaces. At 810, NWDAF 802 subscribes to PCF 134 for UE policies, application policies, and triggering events.
[0076] In some implementations, this subscription request may include PSS policies and application instances. At 815, NWDAF 802 further subscribes to UE mobility information (e.g., locations where UE 110 has been / is currently located, locations where UE 110 has moved, registered areas or tracking areas visited by the UE, etc.) from AMF 132 to use the corresponding UE ID generation pattern to map congestion mitigation and efficient analysis configurations for different times of day. In some implementations, this subscription request may include UE application ID and UE mobility information. In some implementations, NWDAF 802 may request this information from UE 110. However, this would require the UE to accept sharing application and location data with NWDAF.
[0077] At 820, NWDAF 802 prepares data for analysis using additional input from Operations, Application, and Management / Maintenance (OAM). At 825, NWDAF 802 performs data analysis based on UE mobility mode, policy, application type, and the interface used. At 830, NWDAF 802 forwards the analysis to AF 135. In some implementations, the analysis may include UE interface usage, time of day, application usability, interface (PC5 / Uu) usage details, congestion mitigation, and repeater-enabled / UE group communication patterns. At 835, AF 135 may renegotiate / modify the PSS policy based on the analysis and predictions received at 830, according to UE mobility, time of day, and interface usage. In some implementations, AF 135 may also modify the triggering events described above.
[0078] Although this patent application describes various combinations of various embodiments, each with different features, those skilled in the art will understand that any feature of an embodiment can be combined with features of other embodiments or features that are not functionally or logically inconsistent with the operation or function of the device of the disclosed embodiment of the invention in any manner not explicitly denied.
[0079] As is widely recognized, the use of personally identifiable information should comply with privacy policies and practices that are generally accepted to meet or exceed industry or governmental requirements for protecting user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly explained to users.
[0080] Those skilled in the art will understand that the exemplary embodiments described above can be implemented with any suitable software or hardware configuration or combination thereof. Exemplary hardware platforms for implementing the exemplary embodiments may include, for example, Intel x86-based platforms with compatible operating systems, Windows OS, Mac platforms and MAC OS, and mobile devices with operating systems such as iOS, Android, etc. In other examples, exemplary embodiments of the methods described above may be embodied as programs comprising lines of code stored on a non-transitory computer-readable storage medium, which, at compile time, can be executed on a processor or microprocessor.
[0081] It will be apparent to those skilled in the art that various modifications can be made to this disclosure without departing from its spirit or scope. Therefore, this disclosure is intended to cover all modifications and variations thereof, provided that such modifications and variations are within the scope of the appended claims and their equivalents.
Claims
1. A computer-readable storage medium comprising a set of instructions, wherein the set of instructions, when executed by a processor of a user equipment (UE), causes the processor to perform operations, the operations including: It is determined that a triggering event has occurred, wherein the triggering event is based on a set of Proximity Service (ProSe) Path Selection and Switching (PSS) policies; Send an establishment or update request to the Direct Discovery Name Management Function (DDNMF) of the 5G core network; UE-specific policies are received based on the aforementioned set of ProSe PSS policies; as well as Switch from one of the PC5 interface or the Uu interface to the other of the PC5 interface or the Uu interface.
2. The computer-readable storage medium according to claim 1, wherein the triggering event is a UE triggering event.
3. The computer-readable storage medium of claim 1, wherein the triggering event is an application function (AF) triggering event.
4. The computer-readable storage medium of claim 1, wherein the ProSe PSS policy is created by the policy control function (PCF) of the 5G core network in response to a request from the AF of the 5G core network.
5. The computer-readable storage medium of claim 4, wherein the ProSe PSS policy includes at least one of timing criteria, location criteria, QoS criteria, and service criteria.
6. The computer-readable storage medium of claim 1, wherein the received UE-specific policy is an update to a policy already used by the UE.
7. The computer-readable storage medium of claim 1, wherein the DDNMF is a standalone function on the 5G core network.
8. The computer-readable storage medium of claim 1, wherein the DDNMF is juxtaposed with the AF of the 5G core network.
9. The computer-readable storage medium of claim 1, wherein the UE-specific policy includes authorization for the UE to act as a repeater for connecting one or more other UEs to a 5G New Radio (NR) network.
10. A user equipment (UE), comprising: A transceiver configured to connect to a next-generation node (gNB) and another UE; as well as Processor, the processor being configured to: It is determined that a triggering event has occurred, wherein the triggering event is based on a set of Proximity Service (ProSe) Path Selection and Switching (PSS) policies; Send an establishment or update request to the Direct Discovery Name Management Function (DDNMF) of the 5G core network; UE-specific policies are received based on the aforementioned set of ProSe PSS policies; as well as Switch from one of the PC5 interface used for connecting to the other UE or the Uu interface used for connecting to the gNB to the other of the PC5 interface or the Uu interface.
11. The UE according to claim 10, wherein the triggering event is a UE triggering event.
12. The UE of claim 10, wherein the triggering event is an application function (AF) triggering event.
13. The UE of claim 10, wherein the ProSe PSS policy is created by the policy control function (PCF) of the 5G core network, wherein the ProSe PSS policy includes at least one of timing criteria, location criteria, QoS criteria, and service criteria.
14. The UE of claim 13, wherein the PCF creates the ProSe PSS policy in response to a request from the AF of the 5G core network.
15. The UE of claim 10, wherein the received UE-specific policy is an update of a policy already used by the UE.
16. The UE according to claim 10, wherein the DDNMF is a standalone function on the 5G core network.
17. The UE according to claim 10, wherein the DDNMF is co-located with the AF of the 5G core network.
18. The UE of claim 10, wherein the UE-specific policy includes authorizing the UE to act as a repeater for connecting one or more other UEs to a 5G New Radio (NR) network.
19. An integrated circuit configured for use in user equipment (UE), the integrated circuit comprising: A circuit configured to determine that a triggering event has occurred, wherein the triggering event is based on a set of Proximity Service (ProSe) Path Selection and Switching (PSS) policies; A circuit configured to send an establishment or update request to the Direct Discovery Name Management Function (DDNMF) of the 5G core network; A circuit configured to receive UE-specific policies based on the aforementioned set of ProSe PSS policies; as well as A circuit configured to switch from either a PC5 interface for connecting to another UE or a Uu interface for connecting to a next-generation node B (gNB) to the other of the PC5 interface or the Uu interface.
20. The integrated circuit of claim 19, wherein the triggering event is one of a UE triggering event or an application function (AF) triggering event.