WO2026000682A1 - Network triggered registration method - Google Patents

Abstract

A method and system for network-triggered updating of registration of a UE in the network based on a prediction that the registration update will be required for the UE is provided. The network is configured according to the prediction and a Downlink (DL) message is provided to the UE indicative of the parameters and configuration for updating the registration of the UE. The UE may accept the DL message parameters and update its configuration accordingly, may reject the DL message, may send a legacy Uplink (UL) message requesting registration update, may respond with a one or more updated parameter for updating the registration, or may cancel the network-triggered registration method. Timers are provided to manage DL messages and UE responses, and to coordinate and integrate the network-triggered registration update method with the legacy UL-based registration update.

Description

NETWORK TRIGGERED REGISTRATION METHOD

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to United States Provisional Patent Application No. 63/664,367, filed June 26, 2024, the contents of which are incorporated herein by reference.

TECHNICAL FIELD

The present disclosure pertains to the field of registration of a user in a network, and in particular to systems and methods for updating registration of a user in the network.

BACKGROUND

In order to maintain registration of a user (user equipment such as a wireless device) in a network such as a Third Generation Partnership Project (3GPP^TM) 5^th generation (5G) or 6^th generation (6G) network, registration updates are required. These updates are typically initiated by the user and sent to the network as a registration update request Uplink message. The network may receive the request, prepare configurations for updating the registration of the user, and respond to the user. However, such messaging may involve significant overhead which may be inefficient. Additionally, such updating of the user registration is reliant on the user to request the registration update.

Therefore, there is a need for systems and methods for updating registration of a user in the network that obviates or mitigates one or more limitations of the prior art.

This background information is provided to reveal information believed by the applicant to be of possible relevance to the present disclosure. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present disclosure.

SUMMARY

Embodiments disclosed herein provide for a method for updating registration of a user equipment (UE) in a network. The method includes, by one or more network functions of the network, predicting that a registration update will be required for the UE. The method includes, by the one or more network functions of the network, generating, based on the prediction, a downlink (DL) message indicative of information for updating registration of the UE in the network. The method includes, by the one or more network functions of the network, sending the DL message toward the UE.

In an embodiment, the DL message may include predicted parameters characterizing registration of the UE. The method may include configuring the network in accordance with the predicted parameters. The DL message further include information on one or more of configurations of the network and configurations of the UE in accordance with the predicted parameters.

In an embodiment, the DL message may be a paging message or may include paging information.

In an embodiment, the method may further include determining a confined paging area expected to contain the UE based on the prediction, the confined paging area being smaller than a paging area expected to contain the UE based on a last known location of the UE. The method may further include transmitting the DL message for reception only within the confined paging area.

In embodiments, the method may be performed repeatedly a predetermined number of times or during a predetermined time interval, without requiring the UE to respond to the DL messages. The method may further include following the predetermined number of times or the predetermined time interval, requiring an uplink (UL) message from the UE in order to maintain registration of the UE. The UL message from the UE may include a registration update request for registering the UE in the network. The UL message from the UE may include one or more of: an indication that the UE is in communication with the network, an indication that the UE received the DL message, an indication of a present location of the UE, an indication indicating that predicted parameters characterizing registration of the UE and included in the DL message are acceptable to the UE, one or  more updated parameters for correcting a respective one or more predicted parameter characterizing registration of the UE, or a combination thereof.

In embodiments, the one or more network functions include one or more of: an Access and Mobility Management Function (AMF) , a Digital World Control Function (DWCF) , a Digital World Data Processing Function (DWDPF) , a Digital Representative (D-Rep) , a Digital World Digital Network (DW D-Net) platform function, an Access Network (AN) function, a Radio Access Network (RAN) function or a combination thereof.

In an embodiment, the method may further include receiving an uplink (UL) message from the UE indicative of cancellation of generation of the DL message based on the prediction.

In an embodiment, the method may further include implementing a periodic registration update timer for obtaining a registration update request from the UE in accordance with expiry of the periodic registration update timer in order to maintain registration of the UE. The method may further include, in response to an indication that the DL message is in preparation or has been sent toward the UE, beginning a registration update check timer at a predetermined time before the expiry of the periodic registration update timer. The method may further include suspending generating and transmitting of the registration update request from the UE until expiry of the registration update check timer.

In an embodiment, the method may further include implementing a periodic registration update timer for obtaining a registration update request from the UE in accordance with expiry of the periodic registration update timer in order to maintain registration of the UE. The method may further include implementing a periodic registration skip timer which begins counting at the UE in response to an indication that the DL message is received or expected to be received at the UE. The method may further include inhibiting from transmitting the registration update request to the network while the periodic registration skip timer is unexpired. The method may further include, in response to expiry of the periodic registration skip timer, if the DL message is absent at the UE, assessing for an indication that the DL message is being received at the UE or expected to be received at the UE. The method may further include, in response to expiry of the periodic registration skip timer, if the DL message is received at the UE, resetting the periodic registration update timer.

In embodiments, an apparatus is provided. The apparatus includes one or more network functions of the network. The one or more network functions are configured to predict that the registration update will be required for a user equipment (UE) in communication with a network, the UE requiring a registration update for maintaining registration of the UE in the network. The one or more network functions are configured to generate, based on the prediction, a downlink (DL) message indicative of information for updating registration of the UE in the network and send the DL message toward the UE. The system may also include the UE.

Embodiments provide for a method for supporting updating registration of a user equipment (UE) in a network. Describing the registration process, in a first mode of operation, one or more network functions of the network operate in a proactive/predictive mode to: predict that a registration update will be required for the UE; generate, based on the prediction, a downlink (DL) message indicative of information for updating registration of the UE in the network; and send the DL message toward the UE. Further describing the registration process, in a second (e.g. legacy) mode of operation, the UE transmits a registration uplink request message to the network in order to maintain the registration of the UE, in response to expiry of a periodic registration update timer. The method itself may include steps corresponding to one or both of the first and second mode of operation.

In some embodiments, the method includes, e.g. with respect to the first mode of operation, in response to an indication that the DL message is in preparation or has been sent toward the UE, beginning a registration update check timer at a predetermined time before the expiry of the periodic registration update timer. Continuing with such embodiments, the method further includes suspending generating and transmitting of the registration update request from the UE to the network, e.g. with respect to the second mode of operation, until expiry of the registration update check timer.

In some embodiments, the method includes implementing a periodic registration skip timer which begins counting at the UE in response to an indication that the DL message is received or expected to be received at the UE, e.g. with respect to the first mode of operation. Continuing with such embodiments, the method includes, e.g. with respect to the second mode of operation, inhibiting the UE from transmitting the registration update request to the network while the periodic registration skip timer is unexpired.

In some embodiments, the above method further includes, in response to expiry of the periodic registration skip timer: if the DL message is absent at the UE, assessing for an indication that the DL message is being received at the UE or expected to be received at the UE; and if the DL message is received at the UE, resetting the periodic registration update timer.

Embodiments provide for an apparatus or system. For context and with respect to the apparatus, in a first mode of operation, a network operates to: predict that a registration update will be required for a user equipment (UE) ; generate, based on the prediction, a downlink (DL) message indicative of information for updating registration of the UE in the network; and send the DL message toward the UE. In a second mode of operation, the UE transmits a registration uplink request message to the network in order to maintain the registration of the UE, in response to expiry of a periodic registration update timer. The apparatus includes the UE, one or more network functions of the network, or a combination thereof. The apparatus may be configured to perform one or more of the actions mentioned above with respect to the first mode of operation and the second mode of operation.

In some embodiments, the apparatus is configured, e.g. with respect to the first mode of operation, in response to an indication that the DL message is in preparation or has been sent toward the UE, begin a registration update check timer at a predetermined time before the expiry of the periodic registration update timer. Continuing with respect to such embodiments, the apparatus is further configured to suspend generating and transmitting of the registration update request from the UE to the network, e.g. with respect to the second mode of operation, until expiry of the registration update check timer.

In some embodiments, the apparatus is configured to implement a periodic registration skip timer which begins counting at the UE in response to an indication that the DL message is received or expected to be received at the UE, e.g. with respect to the first mode of operation. Continuing with respect to such embodiments, the apparatus is further configured, e.g. with respect to the second mode of operation, to inhibit the UE from transmitting the registration update request to the network while the periodic registration skip timer is unexpired.

In some embodiments, the apparatus is further configured, in response to expiry of the periodic registration skip timer, to: if the DL message is absent at the UE, assess for an indication that the DL message is being received at the UE or expected to be received at the UE; and if the DL message is received at the UE, reset the periodic registration update timer.

In embodiments, a UE is provided which performs operations as described above, with respect to methods or systems. The UE may perform operations which are complementary to those of the network as described above. For example, the UE may manage, set and respond to timers, transmit UL registration requests where appropriate, respond to DL messages, or the like, or a combination thereof.

Embodiments provide for a computer program product comprising a computer readable medium having stored thereon statements and instructions which, when executed by one or more computer processors, cause the one or more computer processors to perform one or more of the above-described methods.

Embodiments have been described above in conjunction with aspects of the present disclosure upon which they can be implemented. Those skilled in the art will appreciate that embodiments may be implemented in conjunction with the aspect with which they are described but may also be implemented with other embodiments of that aspect. When embodiments are mutually exclusive, or are incompatible with each other, it will be apparent to those skilled in the art. Some embodiments may be described in relation to one aspect, but may also be applicable to other aspects, as will be apparent to those of skill in the art.

BRIEF DESCRIPTION OF THE DRAWINGS

Further features and advantages of the present disclosure will become apparent from the following detailed description, taken in combination with the appended drawings, in which:

FIG. 1 illustrates an example communication network, according to embodiments of the present disclosure.

FIG. 2 illustrates network-triggered paging in 5^th Generation (5G) network, according to prior art.

FIGS. 3A-3C illustrate Registration Update procedures from the Third Generation Partnership Project^TM (3GPP^TM) Technical Specification (TS) 23.502 version 19.0.0 titled “Procedures for the 5G System (5GS) ” and dated June 26, 2024, according to prior art.

FIGS. 4A-4C illustrate Service Request procedures from 3GPP^TM TS 23.502, according to prior art.

FIG. 5 illustrates 6^th Generation (6G) System Conceptual Structure, according to embodiments of the present disclosure.

FIG. 6 illustrates an example of Deployment of 6G system -evolutionary solution, according to an embodiment of the present disclosure.

FIG. 7 illustrates an apparatus in a communication system, according to embodiments of the present disclosure.

FIG. 8 illustrates an example a Network for a Digital World (NET4DW) architecture, according to embodiments of the present disclosure.

FIG. 9 illustrates 5G Enhanced network architecture with a Digital World Data Processing Function (DWDPF) and a Digital World Control Function (DWCF) added to support the Digital World (DW) , according to embodiments of the present disclosure.

FIG. 10 illustrates a downlink (DL) Registration Notice, according to embodiments of the present disclosure.

FIG. 11 illustrates a Downlink PageAndRegister Message, according to embodiments of the present disclosure.

FIG. 12 illustrates an example of halting the network pre-configuration and following the legacy registration procedures when the Registration Feedback Skip Timer is reached, according to an embodiment of the present disclosure.

FIG. 13 illustrates an example procedure to be followed when the counter is reached and PageAndRegisterAck () message is to be sent in the uplink (UL) , according to an embodiment of the present disclosure.

FIG. 14 illustrates a legacy method and two exemplary cases to integrate prediction-based registration, according to an embodiment of the present disclosure.

FIG. 15 illustrates a messaging to set new timer values and modes, according to an embodiment of the present disclosure.

FIG. 16 illustrates a procedure for a user equipment/electronic device (UE/ED) to check for a registration update prediction prior to making a registration update request, according to an embodiment of the present disclosure.

FIGS. 17A-17B illustrate a Digital World (DW) -triggered registration update procedures based on the legacy method, according to an embodiment of the present disclosure.

It will be noted that throughout the appended drawings, like features are identified by like reference numerals.

DETAILED DESCRIPTION

The present disclosure sets forth various embodiments via the use of block diagrams, flowcharts, and examples. Insofar as such block diagrams, flowcharts, and examples contain one or more functions and/or operations, it will be understood by a person skilled in the art that each function and/or operation within such block diagrams, flowcharts, and examples can be implemented, individually or collectively, by a wide range of hardware, software, firmware, or combination thereof. As used herein, the term “about” should be read as including variation from the nominal value, for example, a +/-10%variation from the nominal value. It is to be understood that such a variation is always included in a given value provided herein, whether or not it is specifically referred to. The phrase “in embodiments” can be interpreted to mean “in one or more, but not necessarily all embodiments. ”

Embodiments disclosed herein provide methods and systems for a network-triggered prediction-based registration update of UE in the network that includes generating and providing a Downlink (DL) message from the network (i.e., by one or more network function thereof, collectively or cooperatively) to the UE. The DL message is provided based on a prediction that a registration will be required for or by the UE. The DL may include or the prediction may be processed to obtain predicted parameters for updating registration of the UE. The DL may include or the prediction may be processed to obtain (e.g., indications of) configuration of the network and configuration of the UE for updating registration of the UE in the network. The UE may respond to the DL message in a variety of ways that are discussed further herein, for example, the UE may update its configuration in accordance with the DL message if the DL message is acceptable to the UE.

FIG. 1 schematically illustrates a network 10, according to embodiments. The network 10 may be or may include a knowledge sharing network, for example a network configured for sharing information usable at least in part for training AI models. The network includes nodes that carry data, also referred to herein as training data, that can be used to train an AI model. The data (e.g., access to data) may be held across multiple nodes and collectively form a global knowledge dataset for AI model training. Therefore, in a knowledge sharing network, the data can be held across multiple nodes to form a global, cumulative dataset. The AI model can then move between the nodes to learn from local data of each node. The network 10 may include an underlay network 70, such as a transport network. The network may include an overlay network 80, such as a mobile network. The network may include an application-driven network 90. The network may include a radio access network (RAN) 20. The RAN 20 may be a next  generation (e.g., 6th generation (6G) or later) radio access network, or a legacy (e.g., 5th generation (5G) , 4th generation (4G) ) radio access network. In some implementations, the 6G radio access refers to a next generation air interface of standards which may comprise both terrestrial networks (TNs) and non-terrestrial networks (NTNs) . The network 10 may include a core network (CN) 30 that may be dependent or independent of the radio access technology used in the network. The network 10 may include a public switched telephone network (PSTN) 40, the internet 50, and other networks 60. In general, the network enables communication of multiple wireless or wired devices thereof, such as nodes, network elements, servers, databases, switches, routers, orchestrator, etc. Devices having access to training data, resources for training an AI model, or both, are network nodes as referred to herein.

The network may provide content, such as voice, data, video, text, or a combination thereof, via broadcast, multicast, groupcast, unicast, etc. The network may operate by sharing resources, such as carrier spectrum bandwidth, among its constituent elements. The network may provide a wide range of communication services and applications to network users including enhanced Mobile Broadband (eMBB) services, ultra-reliable low-latency communication (URLLC) services, massive machine type communication (mMTC) services, integrated sensing and communication (ISAC) , immersive communication, massive communication, Hyper reliable and low-latency communication, ubiquitous connectivity, integrated AI and communication, and other services that can be provided by a future generation communication system. The network may provide other services and applications such as earth monitoring, remote sensing, passive sensing and positioning, navigation and tracking, autonomous delivery and mobility, etc.

The network may include a terrestrial network, a non-terrestrial network, or a combination thereof. The network may provide a high degree of availability and robustness through a joint operation of a terrestrial network and a non-terrestrial network. For example, integrating a non-terrestrial network (or components thereof) into a terrestrial network can result in a heterogeneous network comprising multiple layers. The heterogeneous network may achieve better overall performance through efficient multi-link joint operation, more flexible functionality sharing, and faster physical layer link switching between terrestrial networks and non-terrestrial networks. The terrestrial network and the non-terrestrial network could be considered sub-systems of the network.

The network may be compliant with one or more regional, national, international, or a combination thereof, standards, such as the Internet Engineering Task Force (IETF) , the European Telecommunications Standards Institute (ETSI^TM) , and the Third Generation Partnership Project (3GPP^TM) .

When in a 5G network RM-REGISTERED state, a UE can have a Mobility Registration Update procedure described generally as follows: “if the current TAI (Tracking Area Identity) of the serving cell (3GPP^TM Technical Specification (TS) 37.340 version 18.1.0 titled “Evolved Universal Terrestrial Radio Access (E-UTRA) and NR; Multi-connectivity; Overall Description; Stage-2” and dated April 3, 2024) is not in the list of TAIs that the UE has received from the network in order to maintain the registration and enable the AMF (Access and Mobility Management Function) to page the UE” , in order The Mobility Registration Update procedure is further performed “to update its capability information or to re-negotiate protocol parameters with the network. ” The above quotations are as described in the 3GPP^TM TS 23.501 version 18.0.0 titled “System architecture for the 5G System (5GS) ” and dated December 21, 2022.

In embodiments of the present disclosure, an alternative Registration Update method is presented based on predictions in a Digital World (DW) and by using Digital Representatives/Digital UEs (D-Reps/D-UEs) . In this case, instead of UE/ED, a DW representative initiates the update based on the predictions on UE/ED’s mobility and services. For the prediction, an entity in the network can operate to predict behaviour of a UE/ED. This prediction can be based on AI, UE modeling, etc. Then, when a prediction is made that the UE/ED will perform a registration update with the network, instead of waiting for the UE/ED to do so, embodiments as described herein can be implemented to cause the network to perform the registration update on behalf of the UE/ED, and inform the UE/ED of same.

In the procedures outlined in the 3GPP^TM TS 23.502 version 18.3.0 titled “Procedures for the 5G System (5GS) ” and dated September 19, 2023, a Registration type indicates if the UE wants to perform “aMobility Registration Update (i.e. the UE is in RM-REGISTERED state and initiates a Registration procedure due to mobility or due to the UE needs to update its capabilities or protocol parameters, or to request a change of the set of network slices it is allowed to use) ” .

The existing procedure includes the List of Protocol Data Unit (PDU) Sessions to Be Activated in relation to the Registration Request and always-on PDU Sessions information: “In the case of Mobility Registration Update, the UE includes in  the List of PDU Sessions to Be Activated the PDU Sessions for which there are pending uplink data. When the UE includes the List of PDU Sessions to Be Activated, the UE shall indicate PDU Sessions only associated with the access the Registration Request is related to. As defined in the 3GPP^TM TS 24.501 version 18.6.0 titled “Non-Access-Stratum (NAS) protocol for 5G System (5GS) ; Stage 3” and dated April 2, 2024, the UE shall include always-on PDU Sessions which are accepted by the network in the List of PDU Sessions to Be Activated even if there are no pending uplink data for those PDU Sessions. ”

The registration update is (heretofore) conventionally only triggered by the UE. In this case, the network is configured after the registration update. This approach causes a delay compared to having the network pre-configured. In particular, the user updates registration in 3 main cases: periodically, in order to remain reachable (Periodic Registration Update) ; upon mobility (Mobility Registration Update) , or to update its capabilities, or re-negotiate protocol parameters (Mobility Registration Update) ; or as part of updates related to emergency and disaster roaming situations.

Registration updates may take place during (Connection Management) CM-IDLE or CM-CONNECTED states. If the registration update takes place during CM-IDLE, it must conventionally follow first a paging message and then the service request procedures indicated in the 3GPP^TM TS 23.502. Conventionally, according to the current 3GPP 5G standard, paging is initiated by the network under the following conditions: “The network shall initiate the paging procedure for 5GS (a5G System (3GPP) consisting of the 5GC (5G Core Network) , 5G-AN (5G Access Network) and UE) services when NAS (Network-attached storage) signalling messages or user data is pending to be sent to the UE in (5G Mobility Management) 5GMM-IDLE mode over 3GPP^TMaccess (see example in figure 5.6.2.2.1.1) and there is no paging restriction applied in the network for that paging. ”

Notably, the above condition does not include any predictions about the registration update.

The paging response is described as follows in the 3GPP^TM TS 23.501: “AUE in CM-IDLE state has no NAS signalling connection established with the AMF over N1 (the interface connecting the UE and AMF) . The UE performs cell selection/cell reselection according to the 3GPP^TM TS 38.304 version 18.0.0 titled “NR; User Equipment (UE) procedures in Idle mode and in RRC Inactive state” and dated January 16, 2024 and PLMN (public land mobile network) selection according to the 3GPP^TM TS 23.122 version 18.6.0 titled “Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode” and dated April 1, 2024. There are no AN signaling connection, N2 connection and N3 connections for the UE in the CM-IDLE state. If the UE is both in CM-IDLE state and in RM-REGISTERED state, the UE shall, unless otherwise specified in clause 5.3.4.1 of the 3GPP^TMTS 23.501, titled “Mobility Restrictions, respond to paging by performing a Service Request procedure (see clause 4.2.3.2 titled “UE Triggered Service Request” of the 3GPP^TM TS 23.502) , unless the UE is in MICO (Mobile Initiated Connection Only) mode (see clause 5.4.1.3 of the 3GPP^TM TS 23.502, titled “Mobile Initiated Connection Only (MICO) mode” ) ; and perform a Service Request procedure when the UE has uplink signalling or user data to be sent (see clause 4.2.3.2 of the 3GPP^TM TS 23.502) . Specific conditions apply for LADN, see clause 5.6.5 of the 3GPP^TM TS 23.501, titled “Support for Local Area Data Network” . When the UE state in the AMF is RM-REGISTERED, UE information required for initiating communication with the UE shall be stored. The AMF shall be able to retrieve stored information required for initiating communication with the UE using the 5G-GUTI. ”

In the 3GPP^TM TS 23.502, paging strategies include “whether to apply sub-area based paging (e.g. first page in the last known cell-id or tracking area (TA) and retransmission in all registered TAs) . ”

There are means to further optimize paging in order to reduce its communications cost in terms of signalling load and network resources in the 3GPP^TM TS 23.502: “by the AMF implementing specific paging strategies (e.g. the N2 Paging message is sent to the (R) AN nodes that served the UE last) ; by the AMF considering Information On Recommended Cells And NG-RAN nodes provided by the (R) AN at transition to CM-IDLE state. The AMF takes the (R) AN nodes related part of this information into account to determine the (R) AN nodes to be paged and provides the information on recommended cells within the N2 Paging message to each of these (R) AN nodes; by the (R) AN considering the Paging Attempt Count Information provided by the AMF at paging. ”

There are means to update the UE paging capabilities: “If the UE Radio Capability for Paging Information is available in the AMF, the AMF adds the UE Radio Capability for Paging Information in the N2 Paging message to the (R) AN nodes. ”

According to heretofore conventional 5G implementations, the network may trigger paging when there is data to be sent as shown in FIG. 2. The only trigger for network to initiate paging is NAS signalling messages or user data that is pending. These triggers do not indicate any predictions about a registration update.

Presently, the network lacks sufficient mechanisms to reap the benefits of a prediction-based registration update mechanism that is triggered by the network. In particular, the Radio Resource Control (RRC) UE registration update messages in the uplink (UL) and downlink (DL) may have large size, which may consume more radio resources. The following parameters are (or may be ) sent in the “Registration Request” message (or a registration update request) from a UE to access network (AN) and/or a UE to (R) AN: AN message (AN parameters, Registration Request (Registration type, Subscription Concealed Identifier (SUCI) or 5G Globally Unique Temporary Identifier (5G-GUTI) or Permanent Equipment Identifier (PEI) , [last visited TAI (if available) ] , Security parameters, [Requested Network Slice Selection Assistance Information (NSSAI) ] , [Mapping Of Requested NSSAI] , [Default Configured NSSAI Indication] , [UE Radio Capability Update] , [UE Mobility Management (MM) Core Network Capability] , [PDU Session status] , [List Of PDU Sessions To Be Activated] , [Follow-on request] , [MICO mode preference] , [Requested Active Time] , [Requested Discontinuous Reception (DRX) parameters for Evolved UMTS Terrestrial Radio Access (E-UTRA) and New Radio (NR) ] , [Requested DRX parameters for Narrowband-Internet of Things (NB-IoT) ] , [extended idle mode DRX parameters] , [Local Area Data Network (LADN) Data Network Name (s) (DNN (s) ) or Indicator Of Requesting LADN Information] , [NAS message container] , [Support for restriction of use of Enhanced Coverage] , [Preferred Network Behaviour] , [UE paging probability information] , [Paging Subgrouping Support Indication] , [UE Policy Container (the list of Public Service Identities (PSIs) , indication of UE support for Access Network Discovery and Selection Policy (ANDSP) , the operating system identifier, Indication of UE Route Selection Policy (URSP) Provisioning Support in Evolved Packet System (EPS) , UE capability of reporting URSP rule enforcement to network, UE capability of supporting Visited Public Land Mobile Network (VPLMN) -specific URSP rules) ] and [UE Radio Capability identification (ID) ] , [Release Request indication] , [Paging Restriction Information] , PEI, [PLMN with Disaster Condition] , [Requested Periodic Update time] , [Unavailability Period Duration] , [Start of Unavailability Period] , [Unavailability Type] ) ) .

In response to the above request, the AMF sends the “Registration Accept” message with (typically) the following parameters: Registration Accept (5G-GUTI, Registration Area, [Mobility restrictions] , [PDU Session status] , [Allowed NSSAI] , [Mapping Of Allowed NSSAI] , [Partially Allowed NSSAI] , [Mapping Of Partially Allowed NSSAI] , [TAI List for Single Network Slice Selection Assistance Information (S-NSSAIs) in Partially Allowed NSSAI] , [Configured NSSAI for the Serving PLMN] , [Mapping Of Configured NSSAI] , [Network Slice Simultaneous Usage Group (NSSRG) Information] , [Network Slice AS Group (NSAG) Information] , [rejected S-NSSAIs] , [TAI List for any rejected S-NSSAI Partially in the RA] , [Pending NSSAI] , [Mapping Of Pending NSSAI] , [Periodic Registration Update timer] , [Active Time] , [Strictly Periodic Registration Timer Indication] , [LADN Information] , [accepted MICO mode] , [IP Multimedia Subsystem (IMS) Voice over Packet Switch (PS) session supported Indication] , [Emergency Service Support indicator] , [Accepted DRX parameters for E-UTRA and NR] , [Accepted DRX parameters for NB-IoT] , [extended idle mode DRX parameters] , [Paging Time Window] , [Network support of Interworking without N26] , [Access Stratum Connection Establishment NSSAI Inclusion Mode] , [Network Slicing Subscription Change Indication] , [Operator-defined access category definitions] , [List of equivalent PLMNs] , [Enhanced Coverage Restricted information] , [Supported Network Behaviour] , [Service Gap Time] , [PLMN-assigned UE Radio Capability ID] , [PLMN-assigned UE Radio Capability ID deletion] , [Wake Up Signal (WUS) Assistance Information] , [AMF Paging Early Indication with Paging Subgrouping (PEIPS) Assistance Information] , [Truncated 5G S-Temporary Mobile Subscriber Identity (5G-S-TMSI) Configuration] , [Connection Release Supported] , [Paging Cause Indication for Voice Service Supported] , [Paging Restriction Supported] , [Reject Paging Request Supported] , [Paging Restriction Information acceptance /rejection] , ["List of PLMN (s) to be used in Disaster Condition" ] , [Disaster Roaming wait range information] , [Disaster Return wait range information] , [Forbidden TAI(s) ] , [List of equivalent stand-alone Non-Public Networks (SNPNs) ] , [Registered Network interface device (NID) ] , [Unavailability Period Supported] , [Mobile Base Station Relay (MBSR) authorization information] , [Discontinuous Coverage Supported] , [Return To Coverage Notification Not Required] , [Unavailability Period Duration] , [S-NSSAI location availability information] , [Mapping Of Alternative NSSAI] , [Slice Usage Policy] , [Maximum Time Offset] ) .

Embodiments disclosed herein provide for replacing the above messages and UE-triggered registration update procedure with network-triggered registration update (also referred to herein as a DL message, a DL registration notice, a DL notice) . As a result, the UL registration message (or registration update request) from the UE is not needed and signaling between the UE and the network is reduced. Additionally or alternatively, as a result, the DL message only uses a subset of the parameters noted above with respect to the “Registration Accept” message and saves RAN resources. Additionally or alternatively, as a result, depending  on the settings, UE-triggered registration can be skipped many (e.g., a predetermined number of) times. If an outcome of implementing methods and procedures according to embodiments disclosed herein is skipping both Service Request and Registration Request procedures, then instead of 4 mandatory messages between the UE and the network, only 1 mandatory message is used (i.e., the DL message from the network to the UE) . For example, if the UE-triggered registration is skipped 5 times, at least 15 messages are (or can be) saved. When the entire registration update process is considered with optional messages, such as Identity Request message, the amount of saved RAN resources further increases correspondingly.

FIGS. 3A, 3B and 3C show the Registration Update procedure according to the 3GPP^TM TS 23.502 and FIGS. 4A, 4B and 4C show the Service Request procedure from the 3GPP^TM TS 23.502. The messages circled in FIGS. 3A-3C and 4A-4C (i.e., “1. Registration Request” 630 of FIG. 3A, “21. Registration Accept” 680 of FIG. 3C, “1. Service Request” 730 of FIG. 4A, and “13. RRC connection reconfiguration” 750 of FIG. 4B) are (or may be) replaced by a single downlink message (DL message) in embodiments of the present disclosure.

Although there are proposals to develop solutions to obtain predictions regarding pro-active network operation and management, there are no detailed solutions on how to use predictions to increase efficiency of the registration (or registration update) process. Embodiments of the present disclosure provide a method to utilize predictions of network registration updates for a user (i.e., UE, ED) . In the heretofore conventional 5G implementation, UE/ED triggers the registration (or registration update) periodically or upon change (e.g., in connection with the network, in UE location, configuration, etc. ) . In embodiments of the present disclosure, instead of the UE/ED triggering the registration or registration update of the UE/ED in the network, the DW/network initiates the update based on the predictions, such as predictions on UE/ED’s mobility, services, etc.

Embodiments of the present disclosure include 3 main points. Firstly, a Registration Update Notice (i.e., the DL message) is sent in the downlink (DL) (e.g., from AMF+) to the UE. This DL Registration Notice replaces UL message (s) sent by the UE for registration updates. The DL Registration notice can be sent using a prediction-based paging method. Further non-limiting examples of how DL Registration Notice can be used in the following scenarios are provided elsewhere herein, however, the network-triggered registration update solution can apply in other cases as well. The scenarios include: a Periodic registration update scenario; and a Non-periodic registration update and no Service Request Message scenario.

Secondly, an example response in the uplink (UL) from the UE to the network in case of a failure of updating registration of the EU according to the DL message, and the acknowledgement mechanism are provided.

Thirdly, procedures and triggers for the prediction-based registration update are provided.

In embodiments, an assumption is made that predictions regarding the parameters of UE registration (or registration update) , such as mobility, service demand, network conditions etc., are available.

Embodiments described herein with reference to FIGS. 10-13 provide a solution to trigger the registration update via the network (network-triggered) when the user (UE) may be not connected with the network, for example when a 5G UE is in CM-IDLE, RM-REGISTERED state. The registration update may be triggered as a result of a prediction. Although the focus of the present disclosure is predictive networking, the embodiments disclosed herein can apply to different kinds of predictions and other scenarios where registration management can benefit from network-triggered operations.

According to an embodiment, predictions are obtained to focus or limit a paging area for paging the UE. Then, a bigger-sized paging message (PageAndRegister message) with registration update notice (DL message) is sent to the UE/ED. Notably, UE/ED must (or may be required to) send capability information indicating that the UE/ED supports this kind of registration technique, prior to this procedure. Examples of a PageAndRegister message that includes a limited paging area for paging the UE are discussed further herein, for example with reference to FIGS. 9, 10, and 11.

In another embodiment, an integration method to ensure or facilitate the coexistence of the proposed network-triggered method with legacy methods is provided. Such integration method examples are discussed further herein, for example with reference to FIG. 14.

In a further embodiment, detailed procedures that include fundamental messaging to utilize prediction-based registration update are provided. These procedures also demonstrate the potential benefits of using such predictions in terms of reducing latency, saving overhead, using less radio resources, or a combination thereof. By combining the registration update information and paging information, this embodiment reduces messaging in the AN and reduces latency.

Embodiments disclosed herein describe an evolutionary solution of a 6G system architecture design and procedure design. The evolutionary solution is designed by enhancement of the 5G system as described herein. The 6G network architecture of the present disclosure has been designed with a few important principles and requirements: openness, trustworthiness, simplicity in standardization, scalability, rapid deployment of 6G networks and future-proofing. The 6G network architecture design of the present disclosure applies modularization strategy, utilizes service-based (Everything as a Service or Anything as a Service (XaaS) ) concepts and network virtualization techniques.

In embodiments, for all of the procedure designs described herein, modularization of procedures may be implemented. A procedure of the 6G System may include some procedures that can be reused by other procedures. Such a reusable procedure is defined as a basic procedure. A complex procedure can, thus, include multiple sequential or parallel basic procedures. It is expected that such methodology can, at least in part, simplify designs of procedures.

In embodiments, the 6G System leverages service-based architecture and XaaS concept. XaaS services in the 6G System are categorized into three layers. The 6G System conceptual structure is discussed elsewhere herein.

In embodiments, with reference to FIG. 5, an Infrastructure Layer 1030 includes infrastructures supporting 6G services, such as wireless networks (Radio Access Network (RAN) 1031, Core Network (CN) ) infrastructures 1032, Cloud/data center infrastructures (not shown) , satellite networks 1033, storage/database infrastructures 1035, sensing networks 1034, and etc. These infrastructures can be provided by a single provider or by multiple providers.

In FIG. 5, each XaaS service is provided by identified 5G logical functions (e.g. as indicated with a “+” next to the acronym) . In the evolutionary solution, a XaaS service can be provided with 5G enhancement by more than one approach. Notably, FIG. 5 is a non-limiting example.

With reference to FIG. 5, the 6G System conceptual structure 1000 has a Service layer 1010 that includes a Network for AI (NET4AI) 1011 that is a new type of service in 6G CN/RAN which enables network with the capability to conduct/execute AI training/inferencing task (s) , i.e. AI task (s) , by network-based computing and communication resources. Herein, the evolutionary solution to support NET4AI service 1011 by enhancing the network data analytics function (NWDAF) in 5G system are described.

At a Service layer 1010, the 6G System conceptual structure 1000 includes a NET4Data service 1012 that provides a decentralized architecture for data stakeholders to collaboratively manage data lifecycle events. These data lifecycle events include data storage and data sharing. The data could be public, private, sensitive, confidential, or a combination thereof. Herein, the NET4Data service 1012 could be integrated into the 5GS, or could be an enhancement of the 5GS.

At a Service layer 1010, the 6G System conceptual structure 1000 includes a Data analysis and management (DAM) service 1013 that focuses on different types of data: network data (e.g., data collected from network functions, XaaS service) , Integrated Sensing and Communications (ISAC) data (3GPP^TM-based sensing data (e.g., from UE and RAN) , Non-3GPP^TM-based sensing data (e.g., from Radar, LiDAR, WiFi^TM Sensing) ) , sensor data (e.g., data from camera sensor, video sensor) , and other data (e.g., Digital user data, 3rd party data, synthetization data, and AI data) . DAM provides services for a variety of data consumers, e.g., XaaS service, 3rd party, Network Function (NF) , UE, etc. 5G system logical functions for example: NWDAF, DCCF, and MFAF of control plane can be enhanced to support DAM service in the evolutionary solution.

At a Service layer 1010, the 6G System conceptual structure 1000 includes a Network for Digital World (NET4DW) 1015 as a service that provides the capability of intelligent integration/synthesis of information from the physical world and digital world (DW) . Customers of NET4DW can be individuals, industries, governments. The customers can have the capability of creation, control, and management of a variety of applications running in the DW such as virtual reality applications. DW services can be supported by enhancing 5G functions and adding new functions (e.g., an evolutionary solution) where necessary.

The 6G System conceptual structure 1000 includes a Network for connectivity (NET4CON) 1016 as a service that provides a capability to support exchange of messages and data among new 6G services. The basic capabilities of NET4CON 1016 include to manage logical topology among XaaS services and between 6G XaaS services and all types of 6G system customers, to introduce intelligent GWs for controlling dynamic forwarding based on configured procedure principle and to support anonymous interactions among these XaaS services and customers by the introduced intelligent GWs. The NET4CON service 1016 is provided by enhancement of the 5G system.

At a C/M layer 1020, the 6G System conceptual structure 1000 includes a Mission Management (MM) 1022 as a service that provides a capability to program provisioning of XaaS services at Service Layer to provide mission services. A mission is to  achieve a designated goal, known as mission goal, which includes providing PDU connectivity and optionally providing data processing. The MM services 1022 include the following: mission information management service, mission session management service, mission execution and access management service.

At a C/M layer 1020, the 6G System conceptual structure 1000 includes a Resource Management (RM) 1021 as a service that provides a capability of life-cycle management of a variety of slices and over-the-air resource assignment to wireless devices.

At a C/M layer 1020, the 6G System conceptual structure 1000 includes a Service Provisioning Management (SPM) 1023 as a service that provides a capability of control and management of 6G service access by customers and provisioning of requested services. The capability is provided by ID management, unified authentication, anonymous service authorization and key management.

At a C/M layer 1020, the 6G System conceptual structure 1000 includes a Connectivity Management (CM) 1024 as a service that provides a capability of reachability management of 6G wireless devices and D-users in NET4DW in order to support connectivity establishment between wireless devices/D-Users and XaaS services of 6G System. Note that physical locations of D-Users can be changed. A CM service can be deployed across multiple Basic Architecture Structure (BAS) domains.

At a C/M layer 1020, the 6G System conceptual structure 1000 includes a Protocol 1026 as a Service provides a capability to design service customized protocol stacks for identified interfaces.

FIG. 6 schematically illustrates one example embodiment of deployment of the 6G system according to the evolutionary solution.

In FIG. 6, “+” sign is used to represent “enhanced” , for example, the 5G AMF-Mobility function is enhanced, and correspondingly denoted in FIG. 6 as AMF-Mobility+ (1122) . Similarly, the 5G Radio Resource Control (RRC) function is enhanced, and correspondingly denoted in FIG. 6 as RRC+ (1123) ; the 5G Network Repository Function (NRF) is enhanced, and correspondingly denoted as NRF+ (1125) ; the 5G Session Management Function (SMF) is enhanced, and correspondingly denoted as SMF+ (1127) ; the 5G Network Exposure Function (NEF) is enhanced, and correspondingly denoted as NEF+ (1128) ; and the 5G Authentication Server Function (AUSF) is enhanced, and correspondingly denoted as AUSF+ (1130) . Other enhanced functions are similarly illustrated in FIG. 6 and are not described in detail herein.

As further shown in FIG. 6, a C/M Radio Bearer (C/M RB) of a 6G device (1152) represents over-the-air connection for carrying control signaling for over-the-air interface management and C/M plane messages. A 6G device can have multiple C/M RBs 1152. A Data Radio Bearer (Data RB) of a 6G device (1154) represents over-the-air connection for carrying Data plane traffic. A 6G device can have multiple Data RBs 1154. A Radio Bearer (RB) endpoint (1155) represents an endpoint of an RB at network side. An endpoint of an RB protocol stack (e.g., Packet Data Convergence Protocol (PDCP) ) can be in, e.g., a RAN BAS domain, but not limited to. In other words, an RB endpoint can be flexibly deployed/selected for a device.

As further shown in FIG. 6, an RB handler (1156) represents an over-the-air interface protocol stack handler. An RB handler 1156 is defined as a logical function which can perform RB protocol stack operations after getting (e.g., receiving, obtaining) suitable configurations. A protocol handler is PDCP-only handler or whole protocol stack handler. The RB handler 1156 accepts RB configuration from a Connectivity Management (CM) service. The RB handler 1156 also accepts security configuration, e.g., keying material, from a Service Provisioning Management (SPM) service.

As further shown in FIG. 6, the NET4CON service 1160, which is a main service impacting on the 6G system architecture, is implemented by an enhanced 5G Service Communication Proxy (SCP+ 1163) as C/M plane GW and by an enhanced 5G User Plane Function (UPF+ 1164) as data plane GW. Proposed per device/D-User C/M session 1161 and data session 1162 are defined as logical connections between a device/D-User 1104 and its serving SCP+ 1163 (C/M-TW-GW) and serving UPF+ 1164 (Data-TW-GW) . All XaaS services are deployed across multiple BAS/clouds, such as BAS domain 1 1111, BAS domain 2 1112, BAS domain 3 1113, RAN Inf (cloud) 1171, CN Inf (cloud) 1172, and 3^rd party clouds 1173.

The 6G customer 1104 can be of a variety of types, including a device (e.g., electronic device ED, terminal device) , UE, apparatus, a chip, an equipment (e.g., user equipment) etc. For example, the customer may be an individual customer, a business customer, etc. The 6G customer may be used to connect persons, objects, machines, etc. The 6G customer may be widely used in various scenarios including, for example, cellular communications, device-to-device (D2D) , vehicle to everything (V2X) , peer-to-peer (P2P) , machine-to-machine (M2M) , Machine Type Communication (MTC) , internet of things (IoT) , virtual reality (VR) , augmented reality (AR) , mixed reality (MR) , metaverse, digital twin, industrial control, self-driving, remote medical, smart grid,  smart furniture, smart office, smart wearable, smart transportation, smart city, drones, robots, remote sensing, passive sensing, positioning, navigation and tracking, autonomous delivery and mobility, etc.

Each 6G customer represents any suitable end user device for wireless operation and may include such devices (or may be referred to but not limited to) as a user equipment (UE) or a user device or a terminal device, a wireless transmit/receive unit (WTRU) , a mobile station, a fixed or mobile subscriber unit, a cellular telephone, a station (STA) , a MTC device, a personal digital assistant (PDA) , a smartphone, a laptop, a computer, a tablet, a wireless sensor, a consumer electronics device, a smart book, a vehicle, a car, a truck, a bus, a train, or an IoT device, wearable devices (such as a watch, a pair of glasses, head mounted equipment, etc. ) , an industrial device, or an apparatus in (e.g. module, modem, or chip) or comprising the forgoing devices, among other possibilities. Future generation 6G customer may be referred to using other terms. When a 6G customer performs (or is configured to perform) a method or methods described herein, it may be interpreted as the ED, one or more module (or units) in the ED, a circuit or chip, or a combination thereof, that may perform the method or methods. For example, the circuit or chip may include a modem chip, also referred to as a baseband chip, a system on chip (SoC) including a modem core, or system in package (SIP) ) , and the like, and may be responsible for one or more communication functions in the ED.

FIG. 7 illustrates an example of an apparatus 320 in a communication system (e.g., the 6G system of FIG. 6) . The apparatus 320 may be an electronic device (e.g. ED, UE or other 6G customer) , a network node such as RAN, any components in RAN, CN or any Network Function of CN, or any apparatus including one or more network functions. As shown in FIG. 7, apparatus 320 may include at least one processor 260. Only one processor 260 is illustrated to avoid congestion in the drawing. The processor 260 may perform (or control the apparatus 320 to perform) operations (or methods) described herein as being performed by the apparatus 320.

When the apparatus is RAN, components of the RAN or the apparatus is the UE, the apparatus 320 may further include a transmitter 252 and a receiver 254 coupled to one or more antennas. One, some, or all of the antennas may alternatively be panels. The transmitter 252 and the receiver 254 may be integrated, e.g. as a transceiver. The transceiver is configured to modulate data or other content for transmission by at least one antenna or network interface controller (NIC) . The transceiver is also configured to demodulate data or other content received by the at least one antenna. Each transceiver includes any suitable structure for generating signals for wireless or wired transmission and/or processing signals received wirelessly or by wire. Each antenna includes any suitable structure for transmitting and/or receiving wireless or wired signals. In present disclosure, the transceiver (or transmitter 252 and/or receiver 254) may be viewed as an interface circuit.

The apparatus 320 may include at least one memory 258. The memory 258 stores instructions used to perform operations described herein. The memory 258 may also store data used, generated, or collected by the apparatus 320. For example, the memory 258 could store software instructions or modules configured to implement some or all of the functionality and/or embodiments described herein and that are executed by one or more processor 260.

A person skilled in the art should understand that embodiments of this application may be provided as a method, an apparatus (or system) , computer-readable storage medium, or a computer program product. Therefore, this application may use a form of a hardware-only embodiment, a software-only embodiment, or an embodiment with a combination of software and hardware. Moreover, this application may use a form of a computer program product that is implemented on one or more computer-usable storage media (including but not limited to a disk memory, an optical memory, and the like) that include computer-usable program code.

Embodiments described herein are presented with a NET4DW architecture 800 described with reference to FIG. 8 in mind, however, this is for a non-limiting reference and some or all embodiments may be implementable on a different network architecture as long as the required or suitable functionalities are present.

In a stand-alone 6G solution (e.g., the NET4DW architecture of FIG. 8) , a Digital Infrastructure (D-Inf) platform 810, Control/Management (C/M) and Data Plane functions include control NS management functionality 820 and data functionality 850, respectively. The necessary C/M functions 820 and Data Plane functions 850 depend on the specific application/service and its requirements. For example, if the Network for a Digital World (NET4DW) gateways (GWs) 805 and 860 may provide sufficient levels of security and anonymity, the trustworthy (TW) GW functionality of the C/M may not be needed. The D-Inf platform may represent a digital world or digital twin of infrastructure, including network infrastructure.

As shown in FIG. 8, D-Inf platform 810 provides 4 main functions in C/M plane 820 and Data plane 850a Data Collection function (DCF) 821 and 851, respectively, for efficient and customizable data collection for D-Reps; a Connection function (CF or CnF) 822 and 852, respectively, for secure connections that can satisfy challenging Quality of Service (QoS) requirement (s) , e.g., low-latency, on a variety of interfaces; a Hosting function (HF) 824 and 854, respectively, for secure hosting of D-Reps and lifecycle management; and an Analysis function (AF or AnF) 825 and 855, respectively, for maintenance of a rich and powerful simulation environment for the optimal effectiveness of D-Reps.

In an alternative implementation, new and enhanced functions may support prediction, particularly the ones with DW, in a 5G evolutionary network architecture (e.g. 6G using evolved versions of 5G functions) as shown in FIG. 8.

FIG. 9 shows functions in the evolutionary solution (e.g., the NET4DW architecture of FIG. 8) , which may include either new additions or enhancements of existing 5G functions.

The Core network (CN) 920 includes a Digital World Control Function (DWCF) 925 and Digital World Data Processing Function (DWDPF) 930, and 5G functions with enhanced services.

The Access network (AN) 910 includes a Radio Management function 911 to provide common radio transmission functions. The Tx/Rx Point 912 can integrate communication and sensing functionalities. The Localization Function 913 of AN 910 can provide location management services provided by the AN 910. The Sensing Function 914 provides sensing functionalities, such as RAN sensing data collection, user privacy protection, etc.

The UE 905, sensor 901 and actuator 902 devices can connect to the CN 920 and a Data network (DN) 960 via the AN 910. The CN 920 provides control plane (CP) 921 connection 923 and data plane (DP) 922 connection 924 with DN 960. The DN 960 can host DW applications in DW AS 962 and controlled by external DWC or application function (AF) 961.

The DWCF 925 provides services to control operation of DW services, including Digital Extended Reality (D-XR) , Digital User (D-User) , and Digital Network (D-Net) , and support 3rd party DW services. General functionalities of DWCF 925 include but are not limited to interacting with (enhanced) Data Collection Coordination Function (DCCF+) 928 for data collection, interacting with ADRF+ 931 for storing collected data, object context data, selecting and configuring of DWDPF, interacting with 3rd DW services, or a combination thereof.

For D-XR services, the DWCF 925 can control D-XR applications running in DWDPF (s) 930; manage virtual computer (hosted in DWDPF 930) for a UE, e.g. for in-network data processing such as split video rendering; support 3rd party XR sessions hosted inside and outside mobile network; or a combination thereof.

The DWCF 925 can support DW by providing the D-User service. General functionalities supported by the D-User service may include managing network feature (s) exposed to D-User such as traffic management, path selection, and/or RAN feature (s) ; tracking and preparing user content interest such as visited websites, downloaded clips, etc.; taking decisions on behalf of a user such as user’s health control, home appliances control, etc.; sharing user data with 3rd parties while preserving privacy controlled by PPP-CP; or a combination thereof.

Functionalities related to D-Inf include supporting network-prediction based operations and orchestrating pre-configuration of the network; deriving the configurations for D-Inf analysis, e.g., predictions for a specific scenario; configuring other network functions to establish the environment for analysis, e.g., subscription requests to DCDF (e.g., DCCF+ (DCDF) 928) ; providing authentication and access configurations for data sharing across different DW entities; or a combination thereof.

The DWDPF 930 provides a hosting platform via DW emulation platform (DWEP) functionality to run DW applications (D-Apps) , such as D-Inf, D-User, D-XR, or combinations of some DW services. Some basic services of DWDPF 930 include Digital World to Real World Adaptation Function (R2DAF) and Real World to Digital World Adaptation Function (D2RAF) services. The R2DAF service is to convert the real world (RW) data to digital world (DW) data that is suitable for specific DW applications. The D2RAF service is to convert the DW data to RW control messages and data for actuators.

For D-XR services, the DWDPF 930 can provide the following services: full XR services hosted in the mobile network that produce XR video and audio streams for user devices by processing multiple video, audio, application data, environmental data streams from UEs, sensors, and application servers; partial XR services, including R2DAF and D2RAF services, for 3rd party XR application servers; In-network computing service for the UE, e.g. split video and audio rendering services, for user XR devices that do not have enough computing resources, or a combination thereof.

The DWDPF 930 allows D-User to control and request special processing for the user and/or D-User traffic data since DWDPF 930 can be controlled by the D-User service provided by the DWCF 925.

D-inf functionalities also include deriving the algorithmic requirements, data requirements and other necessary configurations for prediction-based network optimization; and facilitating data sharing among D-Inf entities, e.g., D-City, D-Robo and between D-Inf entities and external entities.

In embodiments, for an architecture and solution (e.g., as examples described with reference to FIGS. 8 and 9) , the key functionalities supporting this solution are as follows. Firstly, a prediction capability is provided such that the network itself, or a 3rd party, is able to predict when a registration update will be required for a UE/ED.

Accordingly, in embodiments, one or more network functions of the network are configured to predict that a registration update will be required for a UE. One or more network functions are configured to generate, based on the prediction, a DL message (i.e., DL Registration Notice) indicative of information for updating registration of the UE in the network, and sending, transmit or provide the DL message toward the UE.

Secondly, a capability for evaluating the prediction is provided. One or more network functions are provided which are able to obtain, receive and evaluate/understand the prediction messages and act accordingly. In more detail one or more network functions of the network are configured to obtain or receive a corresponding prediction, or prediction information and, based on the received prediction or the prediction information, generate or obtain the prediction that a registration update will be required for a UE. The one or more network functions may include one or more of: an Access and Mobility Management Function (AMF) , a Digital World Control Function (DWCF) , a Digital World Data Processing Function (DWDPF) , a Digital Representative (D-Rep) , a Digital World Digital Network (DW D-Net) platform function, an Access Network (AN) function, a Radio Access Network (RAN) function or a combination thereof. A function for the 6G system or network may be an “enhanced” version of a corresponding 5G function, or may be a new function (e.g., DWCF, DWDPF) .

Thirdly, a UE/ED capability is provided that includes the UE/ED being capable of (e.g., configured to) support the proposed network-triggered registration method (i.e., using the DL message) . The UE/ED is configured to update its registration of the network according to the DL message received by or at the UE/ED, or provided to the UE/ED by one or more network functions. A network function providing the message may be the function that generated the DL message. A network function providing the message may be a function that modified the DL message generated by another function. A network function providing the message may be a function forwarding the DL message received from another function. A combination of the above network functions may be used to provide the message.

Fourthly, an additional functionality that may facilitate the implementation of the network-triggered registration update in some embodiments includes a Network Data Function/Service that includes at least one network function providing data storage services, similar to a Unified Data Management (UDM) , including the UE/ED status data and the UE/ED context data. An example of such a function is referred to herein as “Network Data Function” (NDF) .

Fifthly, another additional functionality that would facilitate the implementation of the network-triggered registration update includes a DW connectivity function/service that includes there at least one network function providing connectivity services between digital-world entities and real-world entities. In one implementation with legacy networks, part or all of these services can be provided by a DW Control Function (DWCF) 925 as shown in FIG. 9. In another implementation with a standalone DW architecture as shown in FIG. 8, part or all of these services can be provided by a “Connection Function” (CnF) .

Sixthly, a further additional functionality that may facilitate the implementation of the network-triggered registration update includes a Digital Entity Emulation function/service that includes at least one function providing emulation, simulation and maintenance services, similar to hosting services. This function may be a DW Emulation platform (DWEP) or hosting and analysis function (s) .

In embodiments, a PageAndRegister counter (also referred to herein as a Registration Feedback Skip Timer) is provided which allows a UE to skip providing or sending an acknowledgement message until the PageAndRegister counter expires (e.g., upon expiry of a predetermined number of times set by the counter or during a predetermined time period set by the counter) to the network (e.g., in response to a DL message) and, therefore reduces messaging and saves RAN resources. The overall PageAndRegister method and messaging described herein makes the PageAndRegister solution useful at least for this reason. PageAndRegister message is a new message and contains useful information to update the registration of the UE during paging.  According to this new paging strategy, an area confinement based on registration update predictions restricting the paging area for registration update is a new idea and saves RAN resources.

In embodiments, shifting a periodic registration timer (i.e., legacy timer that times the UE sending a registration update request in association with the expiry of the periodic registration timer) is an example solution described further herein to facilitate co-existence of the proposed method with the legacy periodic registration update method (e.g., as the current 5G methods described with reference to FIGS. 3A-3C and 4A-4C) .

A first embodiment described further herein with reference to FIGS. 10 and 11 involves using a DL Registration Notice (DL message) sent by the network to replace the UL Registration notice (e.g., registration update request) sent by the UE. A solution to apply this method is provided under this embodiment, where a confined paging signal is or may be used to update registration based on the predictions.

A second embodiment described further herein with reference to FIGS. 12 and 13 involves providing an UL message to handle network-triggered registration updates, including a solution for the PageAndRegister method.

A third embodiment described further herein with reference to FIGS. 14, 15 and 16 involves providing integration methods for DW-triggered solutions to co-exist with legacy solutions. This embodiment clarifies the relationship between the DW-triggered methods and legacy methods.

A fourth embodiment described further herein with reference to FIGS. 17A-17B involves providing a detailed procedure to implement the network-triggered registration update with minimal changes in the legacy registration procedures. While the first two embodiments are somewhat standalone, the last one considers the existing registration methods as the basis.

In embodiments, several timers used in the proposed solutions that are summarized below. Each timer can be configured to count up to or down from a predetermined value, reaching which constitutes expiry of the timer. The predetermined value may be indicative of a number of times a specific action is to be performed or a specific message (s) is to or be provided, obtained, sent, or received. Timers can increment or decrement based on the passage of time, e.g. every second. Additionally or alternatively, timers can increment or decrement based on the observation of certain events, such as communication events. Such timers which increment or decrement based on events can also be referred to as counters.

In an embodiment, a Registration Feedback Skip Timer (also referred to herein as PageAndRegister counter) is provided. When the registration is triggered by the network, instead of the UE/ED, a significant advantage is a capability to skip the UL Registration Request message (i.e., registration update request from the UE) from the UE/ED. However, at certain times, the UE/ED still may need to send an UL message to indicate that it is still alive, etc. Accordingly, the Registration Feedback Skip Timer is used to skip the UL ack message from the UE/ED and to demand an UL message from the UE/ED to ensure its existence in the network in association with timer’s expiry, such as after a predetermined period of time or for a predetermined number of times. In this context “alive” refers to the UE/ED still being present and active with respect to networking activity. For example, if the Registration Feedback Skip Timer is set to 5, the UE/ED will receive 5 network triggered registration messages (DL messages) without sending (or being required to send) any UL messages (e.g., in response to the DL message) . After the 5th time, the UE/ED will be required to send an UL message, e.g., that may include using the legacy registration update request or an acknowledgement of the DL message indicating that the UE/ED is still alive, in the network, etc. Instead of a number of times, the Registration Feedback Skip Timer may be in terms of hours, minutes, etc., depending on the characteristics of the UE/ED and its services, e.g., mobility.

In more detail, and in various embodiments, while the Registration Feedback Skip Timer is unexpired, the UE/ED is not required to respond to a network triggered registration message, and the network does not require such a response to keep the UE/ED registered. However, upon or after the Registration Feedback Skip Timer expires, the UE/ED is required to respond to the latest network triggered registration message if it is to remain registered; and if the network does not receive such a response, preparations are made to de-register the UE/ED. The Registration Feedback Skip Timer can be triggered to begin based for example on receipt of a first network triggered registration message received following the UE/ED’s last UL communication (or UL communication of a particular type e.g. registration message response) to the network.

In various embodiments, the Registration Feedback Skip Timer is used to allow the UE/ED to avoid sending UL messages during a number of prediction-based registration updates. The Registration Feedback Skip Timer value may be used interchangeably with the Page&Register Counter.

In an embodiment, a Page And Register Cancellation Timer is provided. The network-triggered registration update may be cancelled after a certain amount of time or after a number of times, as indicated by the Page And Register Cancellation Timer.

In an embodiment, a Registration Update Check Timer (e.g., 1711 with reference to FIG. 14) is provided. This timer is used to check if a network-triggered registration update will be (or may be, as may be indicative by a DL message being prepared, a prediction being obtained or processed to prepare a DL message, etc. ) sent at a time close to a legacy periodic registration time (e.g., which may be indicated according to the Periodic Registration Update Timer) . This timer facilitates coexistence of the proposed with the legacy method (i.e., UE-triggered registration update using the registration update request) .

In an embodiment, a Periodic Registration Skip Timer (e.g., 1710 with reference to FIG. 14) is provided. This timer is similar to the Periodic Registration Update Timer in the legacy method but applicable to the network-triggered registration update of the present disclosure. The Periodic Registration Skip Timer is a periodic timer used to indicate when it is time to update (or initiate an update of the UE) registration and triggers the network configuration and DL Registration Notice message (i.e., DL message) preparation. Notably, the Periodic Registration Skip Timer may be updated to address changing characteristics of the UE/ED and its services, e.g., mobility changes, service changes. In some cases, the Periodic Registration Skip Timer may be related to the Registration Feedback Skip Timer, e.g., acting as a more granular part of (or in association with, in cooperation with) the Registration Feedback Skip Timer to indicate a timing between a predetermined number of times as indicated by the Registration Feedback Skip Timer. For example, the time between the first skipping of the UL message and the second skipping of the UL message may be indicated by the Periodic Registration Skip Timer.

The Page And Register Cancellation Timer may be configured based on communicated parameters, potentially being configured along with other Page And Register parameters. The Page And Register Cancellation Timer can begin timing starting with the first DL message. This may be the case for example when this timer is counting the number of times to skip the legacy registration update. The Page And Register Cancellation Timer may start at a set time, e.g., 8.8.2025 1: 15 am, and expire at a certain time, e.g. 9.8.2025 2: 23 pm. The Page And Register Cancellation Timer may count the number of times that the Registration Feedback Skip Timer reaches its threshold. For example, the Page And Register Cancellation Timer may increment each time that after Registration Feedback Skip Timer reaches its threshold (e.g. times out) . Accordingly, the Page And Register Cancellation Timer may increment in response to each such (e.g. timeout) event. Once the Page And Register Cancellation Timer reaches its own threshold, e.g. 5 timeout events of the Registration Feedback Skip Timer, the Page-and-Register method may be cancelled and the legacy method may be used instead.

The first embodiment of this disclosure involves sending a DL Registration Notice (i.e., DL message) to the UE/ED as described below by way of an example. A DL message for network-triggered paging and registration update is provided.

In FIG. 10 can be compared to FIGS. 3A-3C and 4A-4C that show the UL Service Request message which then triggers the Registration Request (e.g., registration update request from the UE) . According to FIG. 10, the UL Service Request message and/or Registration Request from UE are replaced with the DL Registration Notice 1320 from the network (i.e., the DL message) . There may or may not be paging prior to the DL Registration Notice 1320 from a Network Function (NF) 1315, such as an AMF. The involvement of the AN node 1310 depends on the connectivity status of the UE/ED 1305. The DL Registration Notice 1320 generated or initiated by a NF 1315 is communicated to the UE/ED 1305 via the AN 1310. The DL message may include predicted parameters characterizing registration of the UE in the network. The DL message may further include configurations of the network and configurations of the UE in accordance with the predicted parameters. The predicted parameters may be used for configuring accordingly, to update the UE registration. The UE, the network, or both, can be configured based on contents of the DL message. The UE can respond to adjust contents of the DL message if necessary. Notably, the parameters that are normally (e.g., with reference to FIGS. 3A-3C and 4A-4C) sent by a UE/ED with an UL Registration Request () (e.g., registration update request) need to be predicted in this embodiment. To derive (or predict) these parameters, non-limiting examples of analysis and predictions may include: Location and mobility predictions; Service predictions, e.g., service types, QoS requirements; Periodical registration timer: obtained from a Certificate Management Function (CMF) (or 5G AMF) , Policy Function (PF) (or 5G Policy Control Function (PCF) ) , or DWCF; List of active PDU sessions, e.g. from CMF, SMF; RAN resources, e.g., to pre-configure Radio Resource Control (RRC) ; Network condition information and predictions, e.g., load as obtained from network data analytics function (NWDAF) , DWCF, management functions and similar; or a combination thereof.

The above analysis may be implemented to help determine one or both of: both registration parameters and the configurations for PageAndRegister method. For example, location and mobility awareness may be used to determine the timer parameters. If the user is predicted to change from one TA to another, based on its location and mobility predictions, the registration feedback skip timer may be reset or shortened to timely prompt or request a response from the user.

Below is a more detailed discussion on the estimated parameters that proposes a solution by combining paging and DL Registration Notice. Notably, the parameter estimations (or predicted parameters) are applicable to any predictive method and not only for the PageAndRegister method.

In embodiments, the PageAndRegister method is provided for updating the paging procedure such that the paging area for paging the UE is confined based on a prediction (e.g., of UE location, mobility, etc. ) and a PageAndRegister message transmitted in this confined area includes the prediction-based registration update (DL message) for the UE/ED. One or more network functions of the network may be configured to determine the confined or limited paging area expected to contain the UE based on the prediction and transmit the DL message for reception only within the confined paging area. The determined confined paging area is smaller than (or at most same as) a paging area expected to contain the UE based on a last known location of the UE.

In some embodiments, confining the paging area may be performed as follows. Normally, a paging message is distributed according to a Tracking Area List (TAL) , which includes a number of base stations which are to distribute the paging message. To confine the paging area, the message may be distributed to only a subset of the TAL.

Accordingly, the PageAndRegister message in this embodiment includes parameters for the registration update, as well as a counter or timer, namely the Registration Feedback Skip Timer, to indicate a predetermined value associated with registration update without feedback from the UE/ED being required. The Registration Feedback Skip Timer may be implemented at the UE/ED, at the network, or both. The UE/ED or the network may check the Registration Feedback Skip Timer. In response, if the Registration Feedback Skip Timer has not reached the threshold value yet, the UE/ED does not need to send feedback response. If the Registration Feedback Skip Timer has reached the maximum threshold value, the UE/ED prepares and sends back the feedback response.

In embodiments, predicting that a registration update will be required for a UE, generating, based on the prediction, a DL message indicative of information for updating registration of the UE in the network, and sending the DL message toward the UE; or conversely, obtaining at the UE from one or more network function, a DL message for updating registration of the UE based on a prediction that a registration update will be required for a UE and indicative of information for updating registration of the UE in the network, may be performed repeatedly a predetermined number of times or during a predetermined time interval (e.g., according to a predetermined value set using the Registration Feedback Skip Timer) without requiring the UE to respond to the DL messages. Following the predetermined number of times or the predetermined time interval, the UE may be required to provide or send a UL message to one or more network function in order to maintain registration of the UE. The predetermined number of times or the predetermined time interval may be determined (e.g., calculated, preset) for example based on a prediction, based on previous one or more registration update, based on a system setting, based on a user setting, based on a UE setting, based on a network setting, or a combination thereof.

In an embodiment, the UL message from the UE may be indicative of cancellation of generation of the DL message based on the prediction. Such UL message may be sent, for example, in response to receiving a DL message at the UE, or at any other suitable time selected by the UE following an indication (e.g., expiry of the Registration Feedback Skip Timer, which may be tracked by the UE itself or indicated in a DL message) that a prediction-based network-triggered registration update method is available in the network for updating UE registration, for example in order to indicate the UE preference or setting to omit updating UE registration based on predictions proactively or upon a corresponding prompt from the network.

In some instances, if the UL message is triggered by the expiry of Registration Feedback Skip Timer, it may be considered to indicate a proactive cancellation. In other instances, a new circumstance, e.g., change of UE’s services, may trigger the UE to proactively cancel the Page And Register method.

In some embodiments, the UL message may be or may include a registration update request for registering the UE in the network, for example if predicted parameters of the DL message are inaccurate or unacceptable to the UE for updating registration. Accordingly, the UL message may be used as the basis for adjusting incorrectly predicted parameters.

In some embodiments, the UL message from the UE may include an indication that the UE is in communication with the network, for example indicative of a threshold value for updating the UE/ED registration without the acknowledgement of the UE/ED. When such threshold value is reached, then the UE/ED has to or may be required to send a response to indicate that it is still in the network. The UL message from the UE may be an acknowledgement such as a PageAndRegisterAck (e.g., 1640 of FIG. 13) . The UL message from the UE may include an indication that the UE received the DL message such as an AliveIndicator (e.g., 1641 of FIG. 13) . The UL message from the UE may include an indication of a present location of the UE such as a LocationIndicator (e.g., 1642 of FIG. 13) . The UL message from the UE may include an indication indicating that predicted parameters characterizing registration of the UE and included in the DL message are acceptable to the UE, such as a ParameterAck (e.g., 1643 of FIG. 13) . The UL message from the UE may include one or more updated parameters for correcting a respective one or more predicted parameter characterizing registration of the UE, for example in ParameterUpdate field (e.g., 1644 of FIG. 13) .

In embodiments, the DL message may be a paging message or may include paging information. Such DL message is referred to herein as a PageAndRegister () , corresponding to the PageAndRegister message, and is a downlink message that is used instead of the traditional (or legacy) paging message (see e.g. FIG. 2, paging message from AN to UE/ED) . Non-limiting examples of parameters that may be included in the PageAndRegister () message include: AN parameters, e.g., 5G-S-TMSI, Selected PLMN ID;NSSAI parameters, mapping, configurations etc.; List of PDU sessions, e.g., to be activated, allowed, modified, their status etc.; an Exempt indication; Assumed NAS message container; Assumed UE capabilities, e.g., Radio Capability, MM Core Network Capability etc.; Follow-on status; MICO mode status; Active Time setting; DRX settings; Enhanced coverage settings; LADN information; Assumed network behavior settings; Policy settings; Paging settings, e.g., periodic update time, capability, subgrouping support etc.; Security settings; RRC configurations; Identity request, where the UE/ED may respond with an Identity Response message (this message may include the SUCI; ideally SUCI is provided by the network, e.g., the D-Rep of the user) ; and combinations thereof. Most of the above parameters are normally sent by the UE/ED but, in the present disclosure, they are derived/assumed/estimated/predicted by the network functions, such as DWDPF, DWCF, NWDAF and so on. These parameters may be obtained with a DW-based solution and may be communicated with the UE/ED for verification purposes.

Furthermore, non-limiting examples of new parameters and prominent prior-art parameters include: Registration Feedback Skip Timer value or predetermined value indicated thereby (used interchangeably with the Page-and-Register Counter in the first embodiment also described with reference to FIG. 10) ; Indication for a PageAndRegisterAck () request; 5G-GUTI, Registration Area, TAI settings; Mobility restriction settings; NSSAI settings, e.g., mapping, configurations, rejected, allowed or partially allowed status and corresponding TAI lists, status (e.g., pending, active) , subscription, policies etc.; Paging settings, e.g., Periodic Registration Update timer and other timing information, paging time window; LADN information; IP Multimedia Subsystem (IMS) settings; Emergency Service Support indicator; Operator-defined access category definitions; PLMN-related information, e.g., list of equivalent PLMNS, PLMN-assigned UE capabilities etc.; DRX and Discontinuous Coverage settings; Other network settings, e.g., Network support of Interworking without N26; and combinations thereof. Most of these parameters are sent by the network as a response to the registration update request in 5G (legacy) . Notably, most of these parameters would not be sent via the paging message, because it is important to keep the size of the paging message limited. The UL parameters are (or may be) predicted and used to configure the network, e.g., AMF selection. Only the updated parameters and/or the most essential parameters may be transmitted to the UE in DL Registration Notice message, and most of them are among the DL Registration Accept message parameters.

In embodiments, the necessary/essential parameters may be determined by the network and/or UE/ED as a part of registration update settings or may be dynamically determined by the network and/or UE/ED based on the situation at hand, e.g., updated parameters, service type, mobility etc. If the required message size is beyond (e.g., at or above) a (e.g. predetermined) threshold size, e.g., PageAndRegisterSizeThreshold, then legacy registration update methods may be used instead. This may lead to updating a Registration Feedback Skip Timer, e.g., to restart it, or to cancel the PageAndRegister method for a time, e.g., for a duration set using a PageAndRegister Cancellation Timer.

In an embodiment, with reference to FIG. 11, the detailed procedures where the PageAndRegister method can be applied may be as follows.

With reference to FIG. 11, a network function such as a DWCF 1420 may receive a RegistrationUpdatePrediction () message 1430 or may produce a prediction itself. This message may generally indicate that the UE/ED 1405 is predicted to require  a registration update currently or shortly in the future. The indication may include that the UE/ED would, under legacy procedures, generate its own registration update request shortly in the future. The prediction may include predicted parameters of the registration update. The parameters of (or included in) the prediction are described elsewhere herein. Some or all of these parameters may be used for generating predicted parameters to be included in a DL message, may be included in the DL message, or both. The DWCF 1420 may have a timer/counter that is or corresponds to a Periodic Registration Skip Timer and the DWCF may initiate the update based on such timer as well. Another trigger may be a prediction produced by a DWEP or D-Rep 1425 or any other function 1421 in the network that indicates a prominent change will (or is likely to) happen, e.g., based on the mobility of the UE/ED, and that a registration update is required (or recommended, or predicted to be required) .

The RegistrationUpdatePrediction () message 1430 may require (e.g., some or all of) the predicted parameters. These parameters may be the UL parameters that would normally (e.g., in legacy operations) be sent by the UE/ED to enable network configurations. For example, a D-Rep may provide AN parameters, such as 5G-S-TMSI or GUAMI, selected PLMN ID, NSSAI information, IAB indication, MBSR indication, Preferred Network Behaviour, List of PDU sessions to be modified/activated, and so on. In another example, some of this information (e.g., some or all of the parameters) may be forwarded to the AMF+ (e.g., AMF+ 1415) and RAN+ (e.g., (R) AN 1410) for them to derive network configurations, as explained further with reference to preparing registration update parameters 1450 and network configurations for registration update 1455. In a further example, e.g., alternatively, all network configurations may be derived by the function (s) that is (are) responsible for the predictions, e.g., a DW D-Net platform, and distributed to the NFs, including DWCF 1420, AMF+ (e.g., AMF 1415) , AN+ (e.g., (R) AN 1410) , etc. In other words, the predicted parameters may be collectively or cooperatively obtained or generated at or by corresponding network functions. Similarly, configurations of the network and configurations of the UE to be included in the DL message in accordance with the predicted parameters may be collectively or cooperatively obtained or generated at or by corresponding network functions.

Further with reference to FIG. 11, during the preparation, the DWCF 1420 may check the Registration Feedback Skip Timer 1435. If the Registration Feedback Skip Timer 1435 has not reached a threshold value (i.e., is unexpired) , the paging message (e.g. 1460, 1461, 1462, 1463) does not require a feedback/acknowledgement from the UE. The rest of the steps in this illustrated embodiment assume that the threshold is not reached.

If the Registration Feedback Skip Timer 1435 has reached the threshold value (is expired or about to expire) , the paging message may require a feedback response from the UE 1405. If such a feedback response is received, the registration update continues. Otherwise, the UE’s registration may expire. The required feedback response may be a new feedback response (e.g., an UL message) as in the second embodiment described elsewhere herein, for example with reference to FIGS. 12 and 13. The required feedback response may be triggering the traditional paging (e.g., UE sending the registration update request, UE cancelling network-triggered registration updates) and not configuring the network. The required feedback response may be a combination of the pre-configured network and traditional method as described elsewhere herein, for example with reference to the third embodiment and FIGS. 14-16.

If it is not already available, UE status and UE context 1440 is (or may be) obtained. Note that the UE/ED status and context 1140 may be monitored/received/requested continuously, and it may be periodic, e.g., if the registration update is periodic. In this case, this step of obtaining the UE status and UE context 1440 is (or may occur) prior to the RegistrationUpdatePrediction () message 1430. In terms of the UE/ED status and context 1140, the D-Rep 1425 of a UE 1405 may provide information such as context, UE ID (e.g. GUTI) , PDU Session IDs, NSSAIs, Slice IDs, and so on. The UE information may be obtained from a network data function (e.g., other function 1421) , such as UDR, UDSF or DAM module. The 5G-GUTI and some other parameters may be obtained with the help of AMF 1415.

Paging area selection 1445 may involve the paging area being confined for this method because (or if) the PageAndRegister () message is larger than a regular (e.g., legacy) paging message. There can be several parameters to determine the paging area selection for registration update, such as: Mobility prediction, e.g., the user’s expected location/cell/TA with current velocity and overall mobility trends; the information on city traffic, road conditions etc., e.g., from a digital representation of the city and roads; Long-term usage statistics of a user, e.g., recorded and analyzed by a D-User module; Last served cell and TA; RAT selection prediction, e.g., based on the predicted service; Slice selection prediction, e.g., based on service; Predictive blockage detection, or a combination thereof. Regarding the Predictive blockage detection, this is a method to collect real-time information about users and environment, and then process this data to predict any possible disruption in the wireless channel. For example,  mmWave links may be disturbed during some time periods if there is a moving physical obstruction moved to a location between the transmitter and the receiver (such as a truck moving by a pedestrian or by a small vehicle to cover the communication path, or due to rain or snow fall, etc. ) .

Preparing registration update parameters 1450 involves determining, based on the prediction, network and UE/ED configuration parameters (e.g., configurations of the network and configurations of the UE in accordance with the predicted parameters) . The registration update parameters 1450 may include predicted parameters. The network and UE/ED configuration parameters for registration update may include: PDU sessions information, e.g., if a new service requiring a new PDU session is predicted, PDU session information may be updated; Slice IDs: similarly, new services or location updates may require new Slice IDs; SMF and other NF information for connectivity, including DW functions (if DW services are going to be used, e.g., for data collection, hosting etc., the connectivity parameters may be updated based on the new location of the user) ; D-Rep IDs: the association of the UE/ED with D-Reps may be updated based on the location, e.g., environmental sensing data collected from other D-Reps and fused with the data of the UE/ED’s D-Rep for analysis; GW information: UE/ED’s new location or services may require updated the serving GWs; Some exemplary legacy parameters with updates (e.g., AMF selection, Cell IDs and serving cell information, configuration of the new AMF if a new one is selected; PLMN ID or similar; UE IDs (e.g., 5G-GUTI) , registration area capability, service timer and other information) ; etc.; or a combination thereof.

Network configurations for registration update 1455 may take place. Configurations of the network may be performed in accordance with the predicted parameters. As described elsewhere herein, e.g., with reference to FIG. 9, the DL Registration Notice replaces Service Request procedures in 3GPP^TM TS 23.502 (summarized with reference to FIGS. 3A-3C and 4A-4C) . The configurations are now done as if the request from the UE 1405 was received. These configurations 1455 may include: UPF selection; N4 Session configuration, e.g., establishment, modification and so on; PDU Session ID (s) and other SMF+ related network configurations, Operation Type, UE location information, Access Type, RAT Type, UE presence in LADN service area, Indication of Access Type can be changed, [MO Exception Data Counter] (3GPP^TM TS 23.502) ; Security context, Mobility Restriction List, list of recommended cells /TAs /NG-RAN node identifiers (3GPP^TM TS 23.502) ; Data repositories, data storage, in-network processing algorithm distributions, Mission management configurations are also among the pre-made configurations; AUSF+, PCF+, UDM+ and other function selections may be completed by the new AMF+; Deregistration of the old AMF+ from the UDM+ and registration of the new AMF+ to the UDM+ (may be new UDM+) may be completed; etc., or a combination thereof.

In embodiments, as described elsewhere herein in more detail, e.g., with reference to FIGS. 10 and 11, the UE/ED-related parameters need to be predicted by the network, e.g., by a DW module/platform. In other words, the network must be capable of predicting any (e.g., one or more) parameter that would (or may be) be sent in the UL with a Registration Update Request, Service Request or similar. For example, AMF+ (e.g., AMF 1415) may use (e.g., some or all of) the predicted values of the following parameters for timer updates: local configuration; expected UE Behaviour; UE indicated preferences; UE capability; UE subscription information; UE availability (for a RAN that provides discontinuous coverage, see clause 5.4.13.1 of the 3GPP^TM TS 23.501, titled “Mobility Management and Power Saving Optimization” ) ; network policies; etc., or a combination thereof. Notably, for the configurations above, there may or may not be buffered data for the user.

A PageAndRegister () message 1460 is prepared with (e.g., using or including) network and UE/ED configurations (e.g., some or all of the predicted parameters, configuration of the UE in accordance with the predicted parameters) and is transmitted in the selected paging area 1455, which may be a restricted area smaller than the conventional paging area, corresponding to a predicted location of the UE. In some cases, parameters of the PageAndRegister () message 1460 may be completed (e.g., obtained, determined) at the step of preparing Network configurations for registration update 1455 described above. Notably, the DL PageAndRegister () message 1460 is similar to the legacy Registration Accept. Therefore, it may, although not necessarily, have a similar content, however, the content must be optimized to respect the size of the DL PageAndRegister () message 1460. If the PageAndRegister () message 1460 parameters (e.g., predicted parameters, configuration of UE, configuration of the network) are not completed (i.e. completely specified) by DWCF 1420, it may be passed 1461 to AMF 1415 and passed 1462 to RAN 1410 (e.g., similar to Figure 4.2.2.2.2. -1 in the 3GPP^TM TS 23.501) to complete the network configurations and determine the necessary parameters thereby, respectively, to be sent 1463 to the UE/ED 1405. Accordingly, the AMF, RAN, or other entities, or a combination thereof, may add parameters to, or adjust parameters of, the PageAndRegister () message. The DWCF 1420 may send 1461 the PageAndRegister () message 1460 to the AMF 1415 for it to be distributed. AMF 1415 may update some of the message  parameters, e.g., 5G-GUTI, Timer values, etc. The AMF+ (e.g., AMF 1415) may forward 1462 the PageAndRegister () message 1460 to the RAN 1410. RAN 1410 may update some of the message parameters before sending 1463 the message 1460, e.g., TAI list. Lastly, the UE/ED 1405 receives 1463 the PageAndRegister () message 1460.

Upon reception 1463 of the PageAndRegister () message 1460, the UE 1405 may check 1470 the Registration Feedback Skip Timer. If the Registration Feedback Skip Timer counter has reached a predetermined threshold (i.e., expired) , the UE may initiate or trigger an UL response message preparation. The Registration Feedback Skip Timer may be updated or reset at the UE. The timer Registration Feedback Skip Timer may be updated (e.g., checked 1475) at the network side as well.

The following embodiments provide example solutions for the UL response message and coordinating the legacy registration method with embodiments disclosed herein.

The second embodiment of the present disclosure involves an Uplink (UL) message for network-triggered paging and registration update (such as the PageAndRegister () message 1460 of FIG. 11, the DL message) and is described below by way of an example. The UL message may be a response of the UE/ED to the network-triggered paging and registration update message (such as the PageAndRegister () message 1460 of FIG. 11) . There are several example types of responses presented in this embodiment and other types of responses may also be possible.

In one example, a response is for when a Registration Feedback Skip Timer reaches a threshold or predetermined value (i.e., expires) . In this case, the threshold value for updating the registration without the acknowledgement of the UE/ED is reached and the UE/ED has to (or is required or requested to) send a response to indicate that it is still in the network in order to maintain its registration in the network.

In an embodiment, when the (Registration Feedback Skip Timer) counter (threshold, predetermined value) is reached, the legacy paging method (e.g., UE sending a registration update request) is (or may be) followed and predictive registration is not (or may not be) utilized. In other words, the network is not (or may not be) pre-configured and registration may be done as a result of the UE/ED’s registration update request, e.g., in a Service Request procedure.

With reference to FIG. 12, the procedure is as follows.

At step 1530, the DWCF 1520 may determine that the Registration Feedback Skip Timer is reached. Alternatively, AMF (e.g., AMF+ 1515) or any other relevant NF 1421 may maintain the timer value.

At step 1535, the DWCF 1520 updates (or may update) network configuration for cancelling or pausing the network-triggered registration processes and related predictions. Notably, in some embodiments, prior to cancelling any prediction, data collection, etc., the DWCF may need to ensure that no other process requires those predictions, data collection, etc. Pausing analyses/processes keeps the resources, e.g., computing, communication etc., reserved. However, cancellation of the network-triggered registration releases the resources. Notices to (R) AN 1510 and AMF (e.g., AMF+ 1515) may be sent to activate legacy registration update procedures. These notices may include any necessary configurations, e.g., UE capability, registration mode, etc.

At step 1540, the UE/ED 1505 sends the UL Registration Request (e.g., registration update request) , e.g., as described in the 3GPP^TM TS 23.502 clause 4.2.2.2.2 titled “General Registration” . The UE/ED may be configured to perform this action for example due to expiry of a legacy internal timer (or an internal version of the Registration Feedback Skip Timer) , and in absence of a registration update being received from the network.

At step 1545, the Registration Update procedures may be enhanced to support DW, e.g., authorization may be done with the help of a D-Rep, or D-Reps may be updated with the new registration parameters.

Accordingly, in various embodiments, the network-initiated registration update approach, for example as described with respect to FIGS. 10 and 11, is performed a predetermined number of times or for a predetermined time period, for example as tracked by the Registration Feedback Skip Timer. Then, following this, a (e.g. legacy) UE-initiated registration update approach is performed.

In another embodiment, illustrated by way of an example in FIG. 13, a PageAndRegister () message 1630 is (or may be) sent by the network (e.g., (R) AN 1610) with an indication to request response from the UE/ED 1605. Alternatively, the message may not contain a timer or an indication of a predetermined value thereof (e.g., Registration Feedback Skip Timer) . However, the UE/ED 1605 may have a timer (e.g., Registration Feedback Skip Timer) of its own (e.g., thereat or otherwise accessible thereto) to trigger the response. Also, timers may exist at both the network side and UE/ED side (they may be coordinated by the DL Registration Notice message) . In this case, the network is (or may be) pre-configured and the UE/ED can send a  PageAndRegisterAck () message 1640, which may be or may include an indication that the UE received the DL message, with any combination of the following parameters.

The PageAndRegisterAck () message 1640 parameters may include an AliveIndicator 1641 indicating that the UE/ED 1605 received the PageAndRegister message 1630. The network may assume that there are no changes in the UE side, for example the UE capability. This may be sent as the sole input, which saves resources by making the message 1630 very small. In another embodiment, this message may be skipped because sending other messages would already indicate that the UE/ED 1605 is able to communicate with the network. If the UE/ED 1605 is not going to be activated, it may not immediately evaluate the parameters of the registration as well.

The PageAndRegisterAck () message 1640 parameters may include an indication of a present location of the UE (LocationIndicator 1642) that is a precise location indicator that may be used for some applications. This location indicator 1642 may have been sensed (or detected) with the help of other devices in the vicinity.

The PageAndRegisterAck () message 1640 parameters may include an indication indicating that predicted parameters characterizing registration of the UE and included in the DL message are acceptable to the UE (ParameterAck 1643) that indicates that the parameters sent with the downlink message (such as the PageAndRegister () message 1460 of FIG. 11) are approved by the UE/ED 1605.

The PageAndRegisterAck () message 1640 parameters may include one or more updated parameters for correcting a respective one or more predicted parameter characterizing registration of the UE (ParameterUpdate 1644) indicating that the parameters sent with the downlink message (such as the PageAndRegister () message 1460 of FIG. 11) , e.g., PDU session IDs, need to be updated. The Parameter update field 1644 can include the name and the value of the parameter, or the parameter name and value can be sent as separate fields/parameters.

Accordingly, in response to a PageAndRegister () message 1630 from the network, the UE may respond under certain conditions with an alive indicator 1641 to indicate that the UE is still present and that registration should be maintained and updated. This response may be required in certain instances for example when the Registration Feedback Skip Timer has expired. Additionally or alternatively, in response to a PageAndRegister () message 1630 from the network, the UE may respond with certain information 1642, 1643, 1644 for example indicating the UE’s location, indicating that (or which) parameters indicated by the PageAndRegister () message 1630 are acceptable, indicating values of some parameters incorrectly included in or omitted in the PageAndRegister () message 1630, or a combination thereof.

In an embodiment, a response from the UE can be provided for when the counter (e.g., Registration Feedback Skip Timer) is not reached but the registration update information needs to be modified. In such embodiment, the UE/ED response may be triggered due to an unacceptable or incorrect parameter in the PageAndRegister () message (e.g., 1630 of FIG. 13) . In this case, the UE/ED may send a Service Request message (e.g., registration update request) , as in the legacy method, however, that is (or may be) wasteful. Another alternative is to simply send a PageAndRegisterNAck () message to reject all of the configurations and wait for a new DL message based on a new prediction. The latter is an efficient solution for when the registration update is not urgent. If the registration update is urgent, and if the UE/ED has capability, it can demand a response with the PageAndRegisterAck () message (e.g., 1640 of FIG. 13) by updating the fields of the corresponding parameters or the ParameterUpdate () field. Accordingly, the message 1640 may be sent by the UE/ED in response to expiry of the Registration Feedback Skip Timer, or else prior to expiry of the Registration Feedback Skip Timer when certain registration parameters require updating or correction. In either case, the Registration Feedback Skip Timer may be reset in response to the message 1640 from the UE/ED.

In an embodiment, an UL response to cancel the network-triggered paging and registration method is provided. At any point, the UE/ED may demand to cancel the network-triggered registration update method. In this case, the UE/ED may respond with the PageAndRegisterAck () message (e.g., 1640 of FIG. 13) with a field indicating cancellation. The cancellation resets the Registration Feedback Skip Timer and upon the reception of cancellation by DWCF, the resources allocated for predictive registration may be released. In order to release the resources, DWCF may need to send reconfiguration messages to DWEP or the D-Rep instances. Also, DCDF may make reconfigurations to cancel subscriptions to alarms, data, analyses, etc. If any in-network processing algorithm was running in the network nodes that are no longer needed, those processes are also (or may also be) cancelled.

In response to the PageAndRegisterAck () , the network may collectively and/or cooperatively, complete the network configurations and update DW parameters in step 1650.

The third embodiment involves methods for Supporting the Legacy and Network-Triggered Registration Update that are described below by way of an example. The relationship between the DW-triggered (or network-triggered) registration method and legacy periodic registration methods is discussed to provide for integration solutions, facilitating co-existence of embodiments of the present disclosure with legacy registration update procedures.

In FIG. 14, the legacy method 1701, and an example first method 1702 and an example second method 1703 to integrate the prediction-based methods with the legacy method 1701 are presented.

With reference to FIG. 14, the second method 1703 includes a Periodic Registration Skip Timer 1710 to skip the UL message (UE Reg. 1721c) of the legacy method 1701. The second method 1703 further includes the Registration Notice (Reg. Notice 1760) . In this embodiment, the Registration Notice 1760 (i.e., DL message) can be the PageAndRegister () message (e.g., 1460 of FIG. 11, 1630 of FIG. 13) in the previous embodiments described elsewhere herein, sent by the network 1720 to the UE/ED 1705. Alternatively, another Registration Notice (similar to 1760) may be received with or without paging preceding the notice. In the second method, predictive registration fails or is inappropriate and the legacy method is used instead (as triggered by UE message 1721c) , after a short delay.

Similarly, the first method 1702 may include the (e.g. legacy) Registration Update (Reg. Update Accept 1765 in FIG. 14) . The Registration Update Accept 1765 may be the Registration Accept message 680 of FIG. 3C. In case of failure, the Registration Update Accept 1765 can correspond to (e.g. be sent in response to) PageAndRegisterNAck () 1721a in the previous embodiments (e.g., with reference to FIG. 13) or it can sent in response to any other failure 1731 which may or may not involve an uplink message. For example, the PageAndRegister method would fail if the counter (e.g., Registration Feedback Skip Timer described elsewhere herein, Periodic Registration Skip Timer 1710) is reached at the Reg. Notice 1760, but no response is received by the network 1720 from the UE/ED 1705. Alternatively, a UE/ED 1705 may proceed with sending an UL Registration Request (e.g., UL UE Reg. Request 1721b, registration update request) , if the parameters in the DL Registration Notice 1760 (or DL Reg. Notice 1761 of the first method 1702) are inaccurate.

In the legacy method 1701, a UE Registration is initiated by the UE 1705 (UL UE Reg. Request 1721a, registration update request) as per the procedures in 3GPP^TM TS 23.502. It is followed by a Registration Update (Reg. Update Accept 1765) at the end of the procedures. The UE 1705 may request the Registration Update regularly, e.g. as set by a Periodic Registration Update Timer 1706. The Periodic Registration Update Timer 1706 may be implemented at the network such that when the Periodic Registration Update Timer 1706 expires in absence of a registration update request (1721a, 1721b, 1721c) from the UE or the DL message, the registration of the UE expires. The Periodic Registration Update Timer 1706 may be implemented at the UE side such that the UE is configured to send a registration update request (1721a, 1721b, 1721c) to the network upon expiry of the Periodic Registration Update Timer 1706. The Registration Update Accept 1765 is a legacy update message. In embodiments, the Periodic Registration Update Timer may be implemented at the UE, at the network, or both, for obtaining a registration update request from the UE before expiry of the Periodic Registration Update Timer in order to maintain registration of the UE.

In the first method 1702, a Reg. Notice (DL Reg. Notice 1760, DL message) is sent from the network 1720 to the UE 1705. This is a new message. This new message (i.e., DL Reg. Notice 1760) indicates that a need for registration update was predicted and the network 1720 is already correspondingly configured for the update. In the legacy method 1701, the UE 1705 initiates the update, but in the first method 1702, the updates are already done on the network side and UE is notified (i.e., via the DL Reg. Notice 1760) . Then, UE 1705 evaluates the contents of the registration notice 1760, which indicates a registration update and may require adjustments, or reject or accept the registration notice and the corresponding registration update indicated thereby. A timer, namely Registration Update Check Timer 1711, may be set at the UE, at the network, or both, during this process to hold on, suspend or inhibit a periodic UL UE Reg. Update Request message 1721c.

The Registration Update Check Timer 1711 may begin with (or start at the time of) : the first step of the prediction-based procedures; during the prediction-based procedures; after the Reg. notice (e.g., 1760, 1761) is received by the UE 1705; any other appropriate time; or a combination thereof. In response to an indication that the DL message is in preparation or has been sent toward the UE, the Registration Update Check Timer may be started at the UE, at the network, or both, at a predetermined time before the expiry of the Periodic Registration Update Timer. Generation (or preparation to generate) and transmission of the  registration update request from the UE until is suspended until expiry of the registration update check timer. Thus, the UE is inhibited from requesting a registration update via the legacy method (e.g. via message 1721b) while the network-initiated registration update operation is in progress, and for some time thereafter, as indicated by the Registration Update Check Timer. –Anew Registration Update Check Timer 1711 may be set around the periodic time to wait for a response or to check for an indication of an ongoing update process. Notably, if the prediction-based registration fails 1731, that may cause a delay in periodic (legacy) registration (i.e., time of UE Reg. 1721b of the legacy method 1701 vs the time of the UE. Reg. 1721c of the first method 1702) . That delay is shown as Failed Predictive Registration Delay 1732 in FIG. 14.

According to various embodiments, the check timer begins before the UE sends its next pending legacy registration update message (e.g. a next copy of message, such as before message 1721b) to the network. The reason for this is to inhibit a clash between such a legacy registration update message and a registration update message sent by the network as described herein. This facilitates coexistence of both the legacy procedure and the network-initiated registration update procedure. The check timer also inhibits duplicate work by the UE and network. For example, following the DL registration notice 1760 in the first method 1702, if the check timer were not implemented, the UE might send its next pending legacy registration update message upon expiry of the periodic registration update timer 1706 (as indicated by the vertical dashed line) . This would cause a duplication and potential clash of updates, because the network was already being configured based on the predictions associated with the network-based registration update corresponding to the DL registration notice 1760.

In the second method 1703, the Registration Notice 1760 (DL message) is sent to the UE 1705 at an unexpected/irrelevant time compared to the Periodic Registration Update Timer 1706. This may be for example a time prior to expiry of the Periodic Registration Update Timer. The Periodic Registration Skip Timer 1710 is implemented at the UE, which begins counting at the UE, at the network, or both, in response to an indication that the DL message is received at the UE, has been sent toward the UE (e.g., via one or more network function or element) or is expected to be received at the UE. The registration update request to the network from the UE is inhibited from being transmitted (or from being prepared) while the Periodic Registration Skip Timer is unexpired. In this case, there are two main options.

According to the first option, the Periodic Registration Update Timer 1706 is not shifted and UE 1705 checks whether there is a need for an update or not after the timer is raised (or reached) . In other words, in response to expiry of the Periodic Registration Skip Timer, if the DL message is absent at the UE, an assessment for an indication that the DL message is being received at the UE or expected to be received at the UE may be made (e.g. at or by the UE) .

A UL Registration Acknowledgement 1762 is also shown, which may be sent in response to the registration notice 1760 and which may acknowledge that the predicted parameters in the registration notice 1760 are correct, or to provide corrected values for such parameters. It is noted that, to save resources, the UL Registration Acknowledgement 1762 is only sent when required.

According to the second option, in response to expiry of the Periodic Registration Skip Timer, if the DL message is received at the UE, the Periodic Registration Update Timer may be reset, paused or adjusted to implement the required shift.

Time 1707 is a shifted expiry time for the Periodic Registration Update Timer 1706, where 1704 is the time at which the periodic registration update timer 1706 would expire, if not shifted. The shift may begin with: the first step of the prediction-based procedures; during the prediction-based procedures; after the Reg. notice 1760 is received by the UE 1705; after the Reg. response is sent by the UE; any other appropriate time; or a combination thereof.

In various embodiments, the Periodic Registration Skip Timer of the third method may be related to the Registration Feedback Skip Timer, and may be directed toward the same purpose.

In various embodiments, the Periodic Registration Skip Timer is used to indicate legacy periodic registration times, so that in case of an issue with or cancellation of the network-initiated registration update, the network can continue operating based on the legacy method. In some embodiments, when the Periodic Registration Skip Timer expires, the UE may send a legacy UL registration message at the next expiry of the Periodic Registration Update timer.

In embodiments, methods for managing new timers are discussed by way of examples. A separate message for configuration may be sent to a UE, e.g., to acknowledge that the UE supports network-triggered registration capability, as shown in FIG. 15. Additionally or alternatively, the UE/ED may check for the predictions before initiating a registration request or to indicate its capability to support the network-triggered prediction based registration method, as shown in FIG. 16. Finally, both the timer values and the capability of the UE/ED may be included in the PageAndRegister () message.

In an embodiment, with reference to FIG. 15, there may be a message exchange between a UE/ED 1805 and a network function 1815, such as AMF+ or DWCF, to update the registration settings and adjust the timer values. The AMF+ 1815 (or DWCF etc. ) may receive the timer update 1820 from another NF, a D-Rep instance, etc., and then send it to the UE in a separate RegistrationUpdate () message 1830. The message 1830 includes (or may include) the new timer mode 1831, e.g., to use it as a guard timer between the prediction-based and legacy registration update methods. The new timer value 1832 of the message 1830 can indicate the shifting amount or the time stamp/value for the timer. Other related parameters, e.g., frequency etc., can also be exchanged. Notably, these parameters could also be included in a legacy message that indicates UE capabilities and timers, e.g., a service request message. This message 1830 may also be used to activate or deactivate prediction-based network-triggered registration methods.

After receiving the RegistrationUpdate () message 1830, the UE 1805 may evaluate 1840 the update parameters and send a RegistrationUpdateAck () 1850 that may include, for example, a PDUSessionList 1851, a TimerValue 1852, or both.

In another embodiment, with reference to FIG. 16, a RegistrationUpdateCheck () message 1930 may be sent to a network function 1915, e.g., AMF+ or DWCF. This message 1930 retrieves any predictions 1940 regarding registration, e.g., next registration update time, next registration update tracking area/cell, etc. These predicted parameters (or predictions 1940 corresponding thereto) may be requested during a legacy registration update or during service request (e.g., registration update request) . These predicted parameters (or predictions 1940 corresponding thereto) may be used to configure legacy and prediction-based registration update methods. For example, Registration Update Check Timer setting may be adjusted based on the prediction parameters (or predictions 1940) . A RegistrationUpdateCheckResponse () message 1950 may be provided to the UE 1905.

Notably, the second method 1703 described above with reference to FIG. 14 proposes to deal with the periodic registration update while it co-exists with the prediction-based method. However, the previously-discussed embodiments suggest other methods, e.g., the PageAndRegister method, which allows the UE to skip sending the UL Reg. Request message (registration update request) for a number of times. By using the proposal (new timers and message parameters) here, the PageAndRegister method, the DL message or another network-triggered registration update method can co-exist with an underlying legacy periodic registration update.

The first method 1702 and the second method 1703 can be implemented to facilitate co-existence of the PageAndRegister method with legacy methods. Method 1702 involves implementing a guard time around a legacy periodic registration timer. Method 1703 involves resetting/restarting the periodic registration timer when prediction-based registration occurs.

In view of the above, embodiments provide for messaging to communicate timer values between the UE and the network (e.g. the AMF or other network entity or network function) . This may be performed for example to synchronize currently running copies of timers in the UE and network. The timer values communicated in this way can indicate the timer settings (e.g. set time or number of events until expiry of a timer) , rules for operating the timer, specific configurable rules for action in response to a timer expiry, etc.

The fourth embodiment involves Network-Triggered Registration Update Procedures that are described below by way of an example. This embodiment proposes a solution to utilize registration update predictions. The solution is based on pre-configuring the network by using DW services to be ready for a registration update. Notably, this solution is based on the legacy method of registration update and the purpose is to utilize the prediction with limited or minimal updates to the existing legacy procedures.

With reference to FIGS. 17A-17B, steps are as follows.

A RegistrationUpdatePrediction () may involve, for example, a prediction 2030 that is (or may be) made by the DW functions (e.g., DWCF 2021, other DW function 2022, D-rep/DWEP 2025) and it indicates (aprediction) that the UE/ED 2005 will need to update registration. There could be other triggers to initiate the Registration update by DW and the trigger shown here (i.e., 2030) is an example among many other possible triggers. Furthermore, the trigger may be internally generated, or may be received from other network analytics functions, including functions such as DAM and NWDAF.

The prediction 2030 may also be received by or via a 3rd party, in which case, the procedures may start with a Requesting 2035 UE/ED Status Update, and a GW may deliver the message to a Network Data Function (e.g., DCDF 2017 as shown in FIGS. 17A-17B) , similar to the 3rd step. The prediction may include some or all of the following parameters (or some or all of these parameters may be derived by another DW function, such as the Connection Function (CnF) in FIG. 8 or DWCF in FIGS. 17A- 17B) : Estimated time for the registration update; UE/ED mobility information, e.g., pattern, speed; Predictive blockage information, e.g., region-based blockage analysis; Disaster alert; AN mobility info, e.g., drone-base-station, discontinuous coverage etc.; AMF selection; Policy updates; UE/ED IDs; UE/ED types; Service types; Slice IDs, e.g., S-NSSAI list; Protocol parameters; Capabilities; UE/ED state confirmation, e.g., confirmation that UE/ED is in the registered state; all, some or any combination of the UL parameters in 3GPP^TM TS 23.502, clause 4.2.2.2.2 (Registration Request) .

As further shown in FIGS. 17A-17B, User status may need to be retrieved from a Network Data Function (NDF) , e.g., DCDF 2017, or the AMF (e.g., New AMF+ 2015, Old AMF+ 2016) . If needed, UE/ED status may be updated by querying (Requesting 2035 UE/ED Status Update) a network data function, similar to UDM+, DCDF 2017 etc. DCDF 2017 is shown in FIGS. 17A-17B as an example. A response (UE/ED Status Update Response 2036) with UE/ED status is (or may be) received. If the UE/ED 2005 is already registered, e.g., RM-REGISTERED state, the procedure can continue. If the UE/ED is not registered, instead of registration update, registration initiate procedures may be followed. The D-Rep 2025 of the UE/ED 2005 may be updated with the latest status information (not shown) .

As further shown in FIGS. 17A-17B, a Mobility Registration Update (RegistrationRequest () 2040) is (or may be) sent to the old AMF (Old AMF+ 2016) . As an alternative, the mobility registration update (2040) may be sent to a GW 2020 that has the functionality to determine the access point for the network and update the registration.

The AMF selection 2045, 2046 can take place (AMF Selection 2045) at the old AMF (Old AMF+ 2016) , (R) AN node 2010, or the GW 2020 (AMF Selection 2046) depending on the implementation. A pre-selected AMF or selection criteria may be indicated in the Registration Request (RegistrationRequest () 2040) . If the AMF selection takes place in the (R) AN 2010, the N2 parameters and more may be defined by AN. These parameters may be related to slicing, service types, pre-filtering, synchronization and so on. If the AMF selection 2046 is done by the GW 2020, parameters regarding the GW 2020 to take care of the new registration, BAS domain information and any other regional information can be derived as parameters. If the AMF selection is done by the old AMF (Old AMF+ 2016) , it may include retrieving information from the network, such as accessing UDR and NRF for information about AMF instances.

As further shown in FIGS. 17A-17B, a registration response is (or may be) prepared. The registration response may be sent 2051a to the new AMF (New AMF+ 2015) , may be sent 2051b to the old AMF (Old AMF+ 2016) , may be sent 2052 to CnF/DWCF 2021, and may be sent 2053 to GW 2020. Alternatively, the GW 2020 may be distributing the response to AN, CnF/DWCF 2021, AMF (New AMF+ 2015, Old AMF+ 2016) and other GW.

The network entities or functions that receive the registration response 2050 may create ACK or NACK messages, with or without reason. For example, the new AMF may reject the parameters or the request. Then, a resolution takes place, e.g., selecting a new AMF, changing parameters etc.

The response 2050 can include: PDU sessions information; Slice IDs; SMF and other NF information for connectivity, including DW functions; D-Rep IDs; GW information; etc., or a combination thereof.

As further shown in FIGS. 17A-17B, UE/ED context is (or may be) requested 2055 by the new connection function, e.g., request 2056 by the new AMF (New AMF+ 2015) . The context may be provided by the DW functions, e.g., by a hosting function that hosts the digital representative of the physical object. The context may be provided by the CnF/DWCF 2021 of the DW 2020. The context may be provided by a Network Data Function, e.g., UDM. The context may also be provided by a plurality of the functions above, where each party has a part of the information. Notably, if the context is provided by the DW 2020, actions to protect the privacy and identity of the user may be used.

A UE/ED context transfer response 2060 is (or may be) sent to the new connection function. The information of the response 2060 can include: D-Rep IDs, DW entity IDs, sub-module IDs and other relevant DW information; Network entity and characteristics information such as AMF, SMF, Policy Function, S-NSSAI (s) , DNN (s) PDU session information; Mission information, in-network processing nodes, in-network processing software information, e.g., analytics IDs; Other network analytics IDs, e.g., NWDAF analytics IDs; or a combination thereof.

An Identity and Authentication Request () 2065 may be sent to retrieve user information if that was not provided previously, e.g., SUCI. This step reduces usage of UE/ED energy and AN resources by not messaging the UE/ED 2005.

Notably, the information is retrieved from the DW may be provided from DW functions in a Trusted Executable Environment and may be masking the actual information of the UE/ED, e.g. as the Identity and Authentication Request () 2070. A  blockchain-based identity may be provided if the Trusted Execution Environment (TEE) /D-Rep/DWEP or another DW function supports blockchain.

As further shown in FIGS. 17A-17B, authorization and security process 2075 takes (or may take) place. Some details are not shown in the call flow but included further herein. The New AMF (New AMF+ 2015) may require PDU sessions information from the old AMF (Old AMF+ 2016) . The New AMF (New AMF+ 2015) may require UE/ED authorization information, e.g., SUPI, from the old AMF (Old AMF+ 2016) . If the PDU sessions in the old AMF (Old AMF+ 2016) cannot be supported by the new AMF (New AMF+ 2015) , a NACK is (or may be) triggered in a following step. The NACK message can include the reason and may be distributed to old AMF (Old AMF+ 2016) , CnF/DWCF 2021 or other DW function 2022, GW 2020, AN, UE 2005 and so on. Authorization information may be requested for UE/ED 2005 as in the legacy system.

The New AMF (New AMF+ 2015) sends (or may send) authorization ACK/NACK 2080 to the CnF/DWCF 2021. Alternativly, the ACK/NACK 2080 may go to old AMF (Old AMF+ 2016) , RAN 2010, GW 2020 or other DW node. This message 2080 may include a reason for the NACK or additional parameters for ACK. This message 2080 may be sent to the GW 2020, D-Rep 2025, CnF/DWCF 2021 or another appropriate NF.

As further shown in FIGS. 17A-17B, the New AMF+ 2015 sends (or may send) a message (e.g., RegistrationUpdate () 2085) to the UE/ED 2005 with the configurations and parameters. This message may be the PageAndRegister () message as in the previous embodiments, if the UE/ED 2005 needs to be paged before sending the message. This message may be a RegistrationUpdate () message 2085. The RegistrationUpdate () message 2085 can be sent to the D-Rep 2025 or GW 2020 or another related NF 2022. If it is sent to the D-Rep 2025, D-rep 2025 is responsible for the update of UE/ED parameters, which can be delayed until there are other messages or communication to be sent to save energy, in cases where a delay is tolerable. The configuration parameters can include the new timer as described elsewhere with reference to FIG. 14, point (b) . The configuration parameters can include an indication to reset /delay the periodic timer as described elsewhere with reference to FIG. 14, point (c) .

In response to the message (e.g., RegistrationUpdate () 2085) , the UE/ED 2005 may send back an ack message (e.g., RegistrationUpdateAck () 2090) . The message may indicate rejection or updates, e.g., provide different GUAMI (s) , not needing some PDU session IDs or an unexpected change in the UE/ED mobility.

In the present disclosure, the terms “a” or “an” are defined to mean “at least one” , that is, these terms do not exclude a plural number of items, unless stated otherwise.

In the present disclosure, terms such as “substantially” , “generally” and “about” , which modify a value, condition or characteristic of a feature of an example embodiment, should be understood to mean that the value, condition or characteristic is defined within tolerances that are acceptable for the proper operation of the example embodiment for its intended application.

In the present disclosure, unless stated otherwise, the terms “connected” and “coupled” , and derivatives and variants thereof, refer herein to any structural or functional connection or coupling, either direct or indirect, between two or more elements. For example, the connection or coupling between the elements can be acoustical, mechanical, optical, electrical, thermal, logical, or any combinations thereof.

In the present disclosure, expressions such as “match” , “matching” and “matched” , including variants and derivatives thereof, are intended to refer herein to a condition in which two or more elements are either the same or within some predetermined tolerance of each other. That is, these terms are meant to encompass not only “exactly” or “identically” matching the two elements but also “substantially” , “approximately” or “subjectively” matching the two or more elements, as well as providing a higher or best match among a plurality of matching possibilities.

In the present disclosure, the expression “based on” is intended to mean “based at least partly on” , that is, this expression can mean “based solely on” or “based partially on” , and so should not be interpreted in a limited manner. More particularly, the expression “based on” could also be understood as meaning “depending on” , “representative of” , “indicative of” , “associated with” or similar expressions.

In the present disclosure, the terms "system" and "network" may be used interchangeably in different embodiments of this application. "At least one" means one or more, and "a plurality of" means two or more. The term "and/or" describes an association relationship of associated objects, and indicates that three relationships may exist. For example, A and/or B may indicate the following three cases: Only A exists, both A and B exist, and only B exists, where A and B may be singular or plural. The character "/" indicates an "or" relationship between associated objects. "At least one of the following items (pieces) " or a similar  expression thereof indicates any combination of these items, including a single item (piece) or any combination of a plurality of items (pieces) . For example, "at least one of A, B, or C" includes: only A; only B; only C; A and B; A and C; B and C; or A, B, and C, and "at least one of A, B, and C" may also be understood as including: only A; only B; only C; A and B; A and C; B and C; or A, B, and C. In addition, unless otherwise specified, ordinal numbers such as "first" and "second" in embodiments of this application are used to distinguish between a plurality of objects, and are not used to limit a sequence, a time sequence, priorities, or importance of the plurality of objects.

This application is described with reference to the flowcharts and/or block diagrams of the method, the device (system) , and the computer program product according to this application. It should be understood that computer program instructions may be used to implement each process and/or each block in the flowcharts and/or the block diagrams and a combination of a process and/or a block in the flowcharts and/or the block diagrams. The computer program instructions may be provided for a general-purpose computer, a dedicated computer, an embedded processor, or a processor of another programmable data processing device and enable a machine to execute the instructions. When executed by any computer or the processor of a programmable data processing device, the instructions cause the apparatus to implement specific functions as described in one or more procedures in the flowcharts and/or one or more blocks in the block diagrams. The computer program instructions may alternatively be stored in a computer-readable memory that can indicate a computer or another programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory generate an artifact that includes an instruction apparatus. The instruction apparatus implements a specific function in one or more procedures in the flowcharts and/or one or more blocks in the block diagrams.

The computer program instructions may alternatively be loaded onto a computer or another programmable data processing device, so that a series of operations and steps are performed on the computer or the another programmable device, so that computer-implemented processing is generated. Therefore, the instructions executed on the computer or on another programmable device provide steps for implementing specific functions as described in one or more procedures in the flowcharts and/or one or more blocks in the block diagrams.

It is clear that a person skilled in the art can make various modifications and variations to this application without departing from the scope of this disclosure. This disclosure is intended to cover these modifications and variations of this application provided that they fall within the scope of protection defined by the following claims and their equivalent technologies.

Although the present disclosure refers to illustrative embodiments with reference to specific features and aspects thereof, this is not intended to be construed in a limiting sense and it is evident that various modifications and combinations can be made thereto without departing from the disclosure. The specification and drawings are, accordingly, to be regarded simply as an illustration of the disclosure as defined by the appended claims, and are contemplated to cover any and all modifications, variations, combinations, or equivalents that fall within the scope of the present disclosure. Various modifications and combinations of the illustrative embodiments, as well as other embodiments of the disclosure, will be apparent to persons skilled in the art upon reference to the description.

Features disclosed herein in the context of any particular embodiments may also or instead be implemented in other embodiments. Method embodiments, for example, may also or instead be implemented in apparatus, system, and/or computer program product embodiments. In addition, although embodiments are described primarily in the context of methods and apparatus, other implementations are also contemplated, as instructions stored on one or more non-transitory computer-readable media, for example. Such media could store programming or instructions to perform any of various methods consistent with the present disclosure.

Claims (22)

1. A method for updating registration of a user equipment (UE) in a network, the method comprising:

   by one or more network functions of the network:

   predicting that a registration update will be required for the UE;

   generating, based on the prediction, a downlink (DL) message indicative of information for updating registration of the UE in the network; and

   sending the DL message toward the UE.
2. The method of claim 1, wherein the DL message includes predicted parameters characterizing registration of the UE.
3. The method of claim 1 or 2, wherein the DL message is a paging message or includes paging information.
4. The method of any one of claims 1 to 3, further comprising:

   determining a confined paging area expected to contain the UE based on the prediction, the confined paging area being smaller than a paging area expected to contain the UE based on a last known location of the UE; and

   transmitting the DL message for reception only within the confined paging area.
5. The method of any one of claims 1 to 4, wherein the method is performed repeatedly a predetermined number of times or during a predetermined time interval, without requiring the UE to respond to the DL messages, the method further comprising: following the predetermined number of times or the predetermined time interval, requiring an uplink (UL) message from the UE in order to maintain registration of the UE.
6. The method of claim 5, wherein the UL message from the UE comprises a registration update request for registering the UE in the network.
7. The method of claim 5 or 6, wherein the UL message from the UE comprises one or more of: an indication that the UE is in communication with the network, an indication that the UE received the DL message, an indication of a present location of the UE, an indication indicating that predicted parameters characterizing registration of the UE and included in the DL message are acceptable to the UE, one or more updated parameters for correcting a respective one or more predicted parameter characterizing registration of the UE, or a combination thereof.
8. The method of claim 2, further comprising configuring the network in accordance with the predicted parameters.
9. The method of claim 2, wherein the DL message further comprises information on one or more of configurations of the network and configurations of the UE in accordance with the predicted parameters.
10. The method of any one of claims 1 to 9, wherein the one or more network functions include one or more of: an Access and Mobility Management Function (AMF) , a Digital World Control Function (DWCF) , a Digital World Data Processing Function (DWDPF) , a Digital Representative (D-Rep) , a Digital World Digital Network (DW D-Net) platform function, an Access Network (AN) function, a Radio Access Network (RAN) function or a combination thereof.
11. The method of any one of claims 1 to 10, further comprising receiving an uplink (UL) message from the UE indicative of cancellation of generation of the DL message based on the prediction.
12. The method of any one of claims 1 to 11, further comprising:

    implementing a periodic registration update timer for obtaining a registration update request from the UE in accordance with expiry of the periodic registration update timer in order to maintain registration of the UE;

    in response to an indication that the DL message is in preparation or has been sent toward the UE, beginning a registration update check timer at a predetermined time before the expiry of the periodic registration update timer; and

    suspending generating and transmitting of the registration update request from the UE until expiry of the registration update check timer.
13. The method of any one of claims 1 to 12, further comprising:

    implementing a periodic registration update timer for obtaining a registration update request from the UE in accordance with expiry of the periodic registration update timer in order to maintain registration of the UE;

    implementing a periodic registration skip timer which begins counting at the UE in response to an indication that the DL message is received or expected to be received at the UE; and

    inhibiting from transmitting the registration update request to the network while the periodic registration skip timer is unexpired.
14. The method of claim 13, further comprising, in response to expiry of the periodic registration skip timer:

    if the DL message is absent at the UE, assessing for an indication that the DL message is being received at the UE or expected to be received at the UE; and

    if the DL message is received at the UE, resetting the periodic registration update timer.
15. An apparatus comprising:

    one or more network functions, the one or more network functions configured to:

    predict that the registration update will be required for a user equipment (UE) in communication with a network, the UE requiring a registration update for maintaining registration of the UE in the network;

    generate, based on the prediction, a downlink (DL) message indicative of information for updating registration of the UE in the network; and

    send the DL message toward the UE.
16. A method for supporting updating registration of a user equipment (UE) in a network, wherein:

    in a first mode of operation, one or more network functions of the network operate to:

    predict that a registration update will be required for the UE;

    generate, based on the prediction, a downlink (DL) message indicative of information for updating registration of the UE in the network; and

    send the DL message toward the UE; and

    in a second mode of operation, the UE transmits a registration uplink request message to the network in order to maintain the registration of the UE, in response to expiry of a periodic registration update timer;

    the method comprising:

    with respect to the first mode of operation, in response to an indication that the DL message is in preparation or has been sent toward the UE, beginning a registration update check timer at a predetermined time before the expiry of the periodic registration update timer; and

    suspending generating and transmitting of the registration update request from the UE to the network, with respect to the second mode of operation, until expiry of the registration update check timer.
17. A method for supporting updating registration of a user equipment (UE) in a network, wherein:

    in a first mode of operation, one or more network functions of the network operate to:

    predict that a registration update will be required for the UE;

    generate, based on the prediction, a downlink (DL) message indicative of information for updating registration of the UE in the network; and

    send the DL message toward the UE; and

    in a second mode of operation, the UE transmits a registration uplink request message to the network in order to maintain the registration of the UE, in response to expiry of a periodic registration update timer;

    the method comprising:

    implementing a periodic registration skip timer which begins counting at the UE in response to an indication that the DL message is received or expected to be received at the UE, with respect to the first mode of operation; and

    with respect to the second mode of operation, inhibiting the UE from transmitting the registration update request to the network while the periodic registration skip timer is unexpired.
18. The method of claim 17, further comprising, in response to expiry of the periodic registration skip timer:

    if the DL message is absent at the UE, assessing for an indication that the DL message is being received at the UE or expected to be received at the UE; and

    if the DL message is received at the UE, resetting the periodic registration update timer.
19. An apparatus, wherein:

    in a first mode of operation, a network operates to:

    predict that a registration update will be required for a user equipment (UE) ;

    generate, based on the prediction, a downlink (DL) message indicative of information for updating registration of the UE in the network; and

    send the DL message toward the UE; and

    in a second mode of operation, the UE transmits a registration uplink request message to the network in order to maintain the registration of the UE, in response to expiry of a periodic registration update timer;

    the apparatus comprising the UE, one or more network functions of the network, or a combination thereof, configured to:

    with respect to the first mode of operation, in response to an indication that the DL message is in preparation or has been sent toward the UE, begin a registration update check timer at a predetermined time before the expiry of the periodic registration update timer; and

    suspend generating and transmitting of the registration update request from the UE to the network, with respect to the second mode of operation, until expiry of the registration update check timer.
20. An apparatus, wherein:

    in a first mode of operation, a network operates to:

    predict that a registration update will be required for a user equipment (UE) ;

    generate, based on the prediction, a downlink (DL) message indicative of information for updating registration of the UE in the network; and

    send the DL message toward the UE; and

    in a second mode of operation, the UE transmits a registration uplink request message to the network in order to maintain the registration of the UE, in response to expiry of a periodic registration update timer;

    the apparatus comprising the UE, one or more network functions of the network, or a combination thereof, configured to:

    implement a periodic registration skip timer which begins counting at the UE in response to an indication that the DL message is received or expected to be received at the UE, with respect to the first mode of operation; and

    with respect to the second mode of operation, inhibit the UE from transmitting the registration update request to the network while the periodic registration skip timer is unexpired.
21. The apparatus of claim 20, further configured, in response to expiry of the periodic registration skip timer, to:

    if the DL message is absent at the UE, assess for an indication that the DL message is being received at the UE or expected to be received at the UE; and

    if the DL message is received at the UE, reset the periodic registration update timer.
22. A computer program product comprising a computer readable medium having stored thereon statements and instructions which, when executed by one or more computer processors, cause the one or more computer processors to perform the method according to any one of claims 1 to 14 or 16 to 18.