Patent Description:
The following abbreviations are herewith defined, at least some of which are referred to within the following description: Third Generation Partnership Project ("3GPP"), Positive-Acknowledgment ("ACK"), Access and Mobility Management Function ("AMF"), Access Network ("AN"), Application Function ("AF"), Application Programming Interface ("API"), Access Point Name ("APN"), Aggregate MBR ("AMBR"), Application Server ("AS"), Connection Management ("CM"), Core Network ("CN"), Communication Pattern ("CP"), Control Plane/User Plane ("CP/UP"), Discontinuous Reception ("DRX"), Downlink ("DL"), Data Network Access Identifier ("DNAI"), Data Network ("DN"), Data Network Name ("DNN"), Domain Name System ("DNS"), Enhanced Discontinuous Reception ("eDRX"), Enhanced Mobile Broadband ("eMBB"), Evolved Node B ("eNB"), Generic Public Subscription Identifier ("GPSI"), Home Public Land Mobile Network ("HPLMN"), Home Subscriber Server ("HSS"), Identity or Identifier or Identification ("ID"), International Mobile Subscriber Identity ("IMSI"), Internet-of- Things ("IoT"), Internet Protocol ("IP"), Long Term Evolution ("LTE"), Multiple Access ("MA"), Maximum Bit Rate ("MBR"), Modulation Coding Scheme ("MCS"), Mobile Country Code ("MCC"), Mobility Management ("MM"), Mobility Management Entity ("MME"), Mobile Network Code ("MNC"), Mobile Network Operator ("MNO"), Machine Type Communication ("MTC"), Master Information Block ("MIB"), Mobile Initiated Connection Only ("MICO"), Mobility Management ("MM"), Mobile Station International Subscriber Directory Number ("MSISDN"), Non-Access Stratum ("NAS"), Narrowband ("NB"), North Bound Interface ("NBI"), Network Parameter Configuration ("NC"), Negative-Acknowledgment ("NACK") or ("NAK"), Network Exposure Function ("NEF"), Next Generation ("NG"), Next Generation Node B ("gNB"), Policy Control Function ("PCF"), Protocol Data Unit ("PDU"), Public Land Mobile Network ("PLMN"), Power Saving Mode ("PSM"), Pointer ("PTR"), Quality of Service ("QoS"), QoS Flow Identifiers ("QFIs"), Radio Resource Control ("RRC"), Radio Access Network ("RAN"), Radio Access Technology ("RAT"), Receive ("RX"), Single Carrier Frequency Division Multiple Access ("SC-FDMA"), Service Capability Exposure Function ("SCEF"), Service Capability Servers ("SCS"), Service Level Agreement ("SLA"), Subscriber Management ("SM"), Subscriber Management Function ("SMF"), Single Network Slice Selection Assistance Information ("S-NSSAI"), Subscriber Identity Module ("SIM"), System Information Block ("SIB"), Short Message Service ("SMS"), Signaling Radio Bearers ("SRBs"), Session and Service Continuity ("SSC"), Subscription Concealed Identifier ("SUCI"), Subscription Permanent Identifier ("SUPI"), Transmit ("TX"), Unified Data Management ("UDM"), User Data Repository ("UDR"), User Entity/Equipment (Mobile Terminal) ("UE"), Universal Integrated Circuit Card ("UICC"), Uplink ("UL"), Universal Mobile Telecommunications System ("UMTS"), User Plane ("UP"), User Plane Function ("UPF"), Visited Public Land Mobile Network ("VPLMN").

In certain wireless communications networks, a remote unit may have various associated behavior parameters. In such networks, network devices associated with the remote unit may receive information corresponding to the behavior parameters.

S2-<NUM> is a 3GPP discussion document titled '<NUM>: Service definition and applies to PDU Session Establishment' submitted by China Mobile, AT&T & Huawei at SA WG2 meeting #<NUM>-bis on <NUM> January <NUM> in Spokane, Washington, USA. This defines the Stage <NUM> procedures and Network Function Services for the <NUM> system architecture which is described in the TS <NUM>. S2-<NUM> is a 3GPP discussion document titled '<NUM>: PDU Session Establishment procedure' submitted by Ericsson, Nokia, Alcatel-Lucent Shanghai Bell & Qualcomm Incorporated at SA WG2 meeting #<NUM>-bis on <NUM> January <NUM> in Spokane, Washington, USA.

Claim <NUM> defines a method for determining remote unit behavior parameters in a Unified Data Management or User Data Repository. Claim <NUM> defines a Unified Data Management or User Data Repository for determining remote unit behavior parameters.

Methods for determining remote unit behavior parameters are disclosed. Apparatuses and systems also perform the functions of the apparatus. In one embodiment, the method includes receiving a message including parameters associated with an application in a remote unit. In various embodiments, the method includes determining a first set of parameters including a first portion of the parameters, wherein each parameter of the first set of parameters corresponds to a remote unit behavior. In certain embodiments, the method includes determining a second set of parameters including a second portion of the parameters, wherein each parameter of the second set of parameters corresponds to a service behavior. In some embodiments, the method includes associating the second set of parameters with a data network name, a single network slice selection assistance information, or a combination thereof.

In one embodiment, receiving the message includes receiving one or more messages, and each of the one or more messages contains a validity time for parameters included therein. In a further embodiment, receiving the message includes receive the message from a network exposure function. In certain embodiments, the method includes transmitting the first set of parameters to an access and mobility management function. In various embodiments, the access and mobility management function determines how to configure the remote unit, a base station, or a combination thereof, based on the first set of parameters.

In some embodiments, the method includes transmitting the second set of parameters to a session management function. In various embodiments, the session management function configures one or more network functions or radio entities using the second set of parameters, and the one or more network functions are configured with information specific to a protocol data unit session, a traffic flow, or a combination thereof. In one embodiment, the parameters include information indicating a preference for either a control plane transmission or a user plane transmission. In various embodiments, the parameters include information indicating an internet protocol address, a port number, or a combination thereof corresponding to a service server, an application server, or a combination thereof. In certain embodiments, the parameters include information indicating an identifier corresponding to a service server, an application server, an application, or some combination thereof.

An apparatus for determining remote unit behavior parameters, in one embodiment, includes a receiver that receives a message including parameters associated with an application in a remote unit. In various embodiments, the apparatus includes a processor that: determines a first set of parameters including a first portion of the parameters, wherein each parameter of the first set of parameters corresponds to a remote unit behavior; determines a second set of parameters including a second portion of the parameters, wherein each parameter of the second set of parameters corresponds to a service behavior; and associates the second set of parameters with a data network name, a single network slice selection assistance information, or a combination thereof.

<FIG> depicts an embodiment of a wireless communication system <NUM> for determining remote unit behavior parameters. In one embodiment, the wireless communication system <NUM> includes remote units <NUM>, network units <NUM>, one or more SCS/AS/AFs <NUM>, and one or more CNs <NUM>. Even though a specific number of remote units <NUM>, network units <NUM>, SCS/AS/AFs <NUM>, and CNs <NUM> are depicted in <FIG>, one of skill in the art will recognize that any number of remote units <NUM>, network units <NUM>, SCS/AS/AFs <NUM>, and CNs <NUM> may be included in the wireless communication system <NUM>.

In one embodiment, the remote units <NUM> may include computing devices, such as desktop computers, laptop computers, personal digital assistants ("PDAs"), tablet computers, smart phones, smart televisions (e.g., televisions connected to the Internet), set-top boxes, game consoles, security systems (including security cameras), vehicle on-board computers, network devices (e.g., routers, switches, modems), IoT devices, or the like. The remote units <NUM> may communicate directly with one or more of the network units <NUM> via UL communication signals.

In certain embodiments, a network unit <NUM> may also be referred to as an access point, an access terminal, a base, a base station, a Node-B, an eNB, a gNB, a Home Node-B, a relay node, a device, a network device, or by any other terminology used in the art. Further, the CN <NUM> may communicate with the SCS/AS/AF <NUM> which may be under control of the same network operator (as the radio access and core networks) or another service provider or operator. In some embodiments, a network unit <NUM> may include one or more of the following network components a gNB, a NG-RAN node, and/or a RAN node. The CN <NUM> may include an MME, an HSS, an SCEF, an AMF, an SMF, an NEF, a DB, a PCF, a UDR, a UPF, and/or a UDM.

In one implementation, the wireless communication system <NUM> is compliant with the LTE of the 3GPP protocol, wherein the network unit <NUM> transmits using an OFDM modulation scheme on the DL and the remote units <NUM> transmit on the UL using a SC-FDMA scheme or an OFDM scheme. More generally, however, the wireless communication system <NUM> may implement some other open or proprietary communication protocol, for example, WiMAX, among other protocols.

In various embodiments, a network unit <NUM> may receive a message including parameters associated with an application in a remote unit <NUM>. In various embodiments, the network unit <NUM> may determine a first set of parameters including a first portion of the parameters, wherein each parameter of the first set of parameters corresponds to a remote unit behavior. In certain embodiments, the network unit <NUM> may determine a second set of parameters including a second portion of the parameters, wherein each parameter of the second set of parameters corresponds to a service behavior. In some embodiments, the network unit <NUM> may associate the second set of parameters with a data network name, a single network slice selection assistance information, or a combination thereof. Accordingly, a network unit <NUM> may be used for determining remote unit <NUM> behavior parameters.

In certain embodiments, a network unit <NUM> may receive a message including a third set of parameters. In various embodiments, the network unit <NUM> may determine a fourth set of parameters including a first portion of the third set of parameters, wherein each parameter of the fourth set of parameters corresponds to remote unit session behavior. In certain embodiments, the network unit <NUM> may determine a fifth set of parameters including a second portion of the third set of parameters, wherein each parameter of the fifth set of parameters corresponds to a service behavior. Accordingly, a network unit <NUM> may be used for determining remote unit <NUM> behavior parameters.

<FIG> depicts one embodiment of an apparatus <NUM> that may be used for transmitting and/or receiving messages. The apparatus <NUM> includes one embodiment of the remote unit <NUM>. Furthermore, the remote unit <NUM> may include a processor <NUM>, a memory <NUM>, an input device <NUM>, a display <NUM>, a transmitter <NUM>, and a receiver <NUM>. In some embodiments, the input device <NUM> and the display <NUM> are combined into a single device, such as a touchscreen. In certain embodiments, the remote unit <NUM> may not include any input device <NUM> and/or display <NUM>. In various embodiments, the remote unit <NUM> may include one or more of the processor <NUM>, the memory <NUM>, the transmitter <NUM>, and the receiver <NUM>, and may not include the input device <NUM> and/or the display <NUM>.

In some embodiments, the memory <NUM> stores data relating to network registration.

The transmitter <NUM> is used to provide UL communication signals to the network unit <NUM> and the receiver <NUM> is used to receive DL communication signals from the network unit <NUM>.

<FIG> depicts one embodiment of an apparatus <NUM> that may be used for determining remote unit <NUM> behavior parameters. The apparatus <NUM> includes one embodiment of the network unit <NUM>. Furthermore, the network unit <NUM> may include a processor <NUM>, a memory <NUM>, an input device <NUM>, a display <NUM>, a transmitter <NUM>, and a receiver <NUM>. As may be appreciated, the processor <NUM>, the memory <NUM>, the input device <NUM>, the display <NUM>, the transmitter <NUM>, and the receiver <NUM> may be substantially similar to the processor <NUM>, the memory <NUM>, the input device <NUM>, the display <NUM>, the transmitter <NUM>, and the receiver <NUM> of the remote unit <NUM>, respectively.

In various embodiments, the receiver <NUM> receives a message including parameters associated with an application in a remote unit <NUM>. In various embodiments, the processor <NUM>: determines a first set of parameters including a first portion of the parameters, wherein each parameter of the first set of parameters corresponds to a remote unit behavior; determines a second set of parameters including a second portion of the parameters, wherein each parameter of the second set of parameters corresponds to a service behavior; and associates the second set of parameters with a data network name, a single network slice selection assistance information, or a combination thereof.

In one embodiment, the receiver <NUM> receives a message including a third set of parameters. In various embodiments, the processor <NUM>: determines a fourth set of parameters including a first portion of the third set of parameters, wherein each parameter of the fourth set of parameters corresponds to remote unit session behavior; and determines a fifth set of parameters including a second portion of the third set of parameters, wherein each parameter of the fifth set of parameters corresponds to a service behavior. Although only one transmitter <NUM> and one receiver <NUM> are illustrated, the network unit <NUM> may have any suitable number of transmitters <NUM> and receivers <NUM>.

<FIG> illustrates one embodiment of communications <NUM> of remote unit <NUM> behavior parameters. Specifically, communications <NUM> between an MME <NUM>, an HSS <NUM>, an SCEF <NUM>, and an SCS/AS <NUM> are illustrated. As may be appreciated, any of the communications <NUM> described herein may be considered messages and/or parts of messages. In certain embodiments, the communications <NUM> may be similar to TS <NUM>.

In some embodiments, a first communication <NUM> from the SCS/AS <NUM> to the SCEF <NUM> may include the SCS/AS <NUM> sending an update request to the SCEF <NUM>. In certain embodiments, the update request may include CP parameters, such as the CP parameters described in Table <NUM>.

In various embodiments, the SCEF <NUM> may select <NUM> a CP parameter. In some embodiments, a second communication <NUM> from the SCEF <NUM> to the HSS <NUM> may include the SCEF <NUM> sending an update CP parameter request. In certain embodiments, the HSS <NUM> may update <NUM> a UE subscription.

In a third communication <NUM> from the HSS <NUM> to the SCEF <NUM>, the HSS <NUM> may send an update CP parameter response. In various embodiments, a fourth communication <NUM> from the SCEF <NUM> to the SCS/AS <NUM> may send an update response. In certain embodiments, the HSS <NUM> may provide <NUM> CP parameters and/or a deletion notice to the MME <NUM>. While CP parameters are described in relation to <FIG>, some embodiments may include one or more CP parameters (e.g., as found in Table <NUM>), one or more expected UE behavior parameters (e.g., as found in Table <NUM>), and/or one or more NC parameters (e.g., as found in Table <NUM>). As may be appreciated, Table <NUM> parameters may be specified for a <NUM> system and may also be used in a <NUM> system (e.g., evolved packed system). Moreover, additional parameters are described herein as described in various embodiments and may be applicable to any of Table <NUM>, Table <NUM>, and/or Table <NUM>, or used independent of the mentioned tables. One such parameter set not mentioned in Tables <NUM> - <NUM> may be parameters for policy information, e.g., infrastructural policy (policies to protect platforms and network, e.g., for ensuring that a service node such as SMS-SC is not overloaded), business policy (policies related to the specific functionalities exposed, e.g., number portability, service routing, subscriber consent, etc.), or application layer policy (policies that are primarily focused on message payload or throughput provided by an application, e.g. how to throttle traffic from this application). Other such parameters not mentioned in Tables <NUM> - <NUM> may be an SCS/AS/AF ID, an SCS/AS source IP address/port number, an SSC mode preference, a CP/UP transmission preference, a DNAI, an expected number of uplink/downlink packets, and/or other parameters as described in certain embodiments herein. All parameters mentioned in this paragraph, but not limited to, may be referred to as CP/NC parameters.

As used herein, UE behavior related parameters (e.g., CP/NC parameters) may refer to communication pattern parameters, network parameter configuration parameters, and/or other parameters. In some embodiments, CP/NC parameters may be sent from AFs, SCSs, and/or ASs over different APIs exposed by a NEF and/or SCEF. In certain embodiments, an MME and/or AMF may use these CP/NC parameters for RAN configuration tuning and/or MM parameter(s) for UE configuration tuning (e.g., PSM mode timer, eDRX timer, etc.).

In various embodiments, CP/NC parameters associated with an application in a UE may include: a CP parameter set (e.g., a time at which traffic is expected to be sent and/or received) which may include - a stationary parameter, a periodic time, a communication duration, a communication schedule, an SCS/AS ID, an SCS/AS IP address, and so forth; an NC parameter set which may include - a maximum response time, a maximum latency, a suggested number of DL packets, a CP/UP delivery preference, and so forth; and/or a UE moving trajectory.

As may be appreciated, certain CP/NC parameters may be best used and/or processed in an AMF and other CP/NC parameters may be best used and/or processed in an SMF. For example, a UE moving trajectory or stationary parameter may be best processed in the AMF. As another example, other parameters like a suggested number of DL packets may be best processed in the SMF (e.g., to properly configure a UPF).

In certain embodiments, at least some of the CP/NC parameter set may describe an application and/or service behavior rather than UE behavior, especially if a UE uses multiple applications (e.g., multiple SCS/ASs). In such embodiments, at least some of the CP/NC parameters may be associated with one or more corresponding PDU sessions, but not with a general UE behavior. Moreover, in response to a PDU session serving an SCS/AS not currently being established, then CP/NC parameters may not influence a network configuration for a corresponding UE.

In some embodiments, a UDM/UDR may categorizes CP/NC parameters into at least CP/NC MM parameters, CP/NC SM parameters, and/or CP/NC policy parameters. In such embodiments, at least the SM parameters may be associated with a particular subscribed DNN and/or S-NSSAI. Moreover, the UDM/UDR may determine whether there is a single application or multiple applications on a UE (which may be equal to a single SCS/AS or multiple SCS/ASs). The CP/NC policy parameters are used by the PCF to derive policy rules for the relevant UE's application(s) and PDU Session(s). If there are multiple SCS/ASs associated with the same DNN, a traffic filter (e.g., based on an SCS/AS's IP address) may be used to differentiate traffic from/to multiple SCS/ASs within a same DNN/S-NSSAI. In certain embodiments, the UDM/UDR may use a SCS/AS ID to determine a corresponding DNN and S-NSSAI. In various embodiments, in response to CP/NC parameters being configured and/or updated in a UDM, the UDM may update only an AMF or an SMF associated with the updated MM parameters and/or SM parameters. In some embodiments, in response to CP/NC parameters being configured and/or updated in an NEF, the NEF may update only an AMF or an SMF associated with the updated MM parameters and/or SM parameters.

In certain embodiments, an SMF may receive either an entire CP/NC parameter set sent from NEF/SCEF or CP/NC SM parameters. The SMF may derive PDU session specific characteristics and/or behaviors based on the received parameters. For example, the SMF may derive: configuration parameters for UPF configuration (e.g., a number of buffered downlink packets, how long time packets should be buffered (e.g., determined based on a maximum latency parameter, etc.)); SMF to NG-RAN (e.g., the SMF sends this information during UP connection activation) CP/NC N2 SM information which may include new parameters to influence NG-RAN settings for a radio interface, e.g. known as Uu interface in the 3GPP specifications, (e.g., the NG-RAN node can use these parameters to determine whether to activate RRC inactive state and the corresponding state configuration; and/or for RRC Connected state configuration (e.g. to derive the Inactive time value)); SMF to AMF (e.g., during PDU session establishment or UP connection activation) session parameters (e.g., PDU session specific parameters for UE behavior such as maximum response time being used to configure eDRX or a periodic registration timer when MICO mode is used. RRC inactive state assistance information derived by an AMF may be extended to include new parameters sent from the SMF, but parameters such as periodic time may be signaled from SMF to AMF to be used); SMF-triggered UP connection deactivation or PDU session release; and/or a switch between a control plane to UP delivery mechanism of data (e.g., small data). Please note that according to certain embodiments, the AMF sends RRC inactive assistance information to the NG-RAN node and the additional information described herein may be sent from the SMF in CP/NC N2 SM information to the NG-RAN node to determine the RRC inactive state configuration or RRC connected state configuration.

In some embodiments, a UDM/UDR may not process and/or classify received CP/NC parameters, but may store the CP/NC parameters as session management parameters relevant to a particular DNN and/or S-NSSAI. In such embodiments, the SMF may receive all CP/NC parameters and may processes and/or classify the parameters into MM parameters to be send to an AMF and SM parameters to be further locally processed at the SMF.

In certain embodiments, there may be a SLA between an SCS/AS/AF and an MNO (in case that the SCS/AS/AF is owned or operated by a third party). In such embodiments, a UDR/UDM may associate an SCS/AS ID with at least a subscribed DNN (or APN) or network slice information (e.g., S-NSSAI). <FIG>Fehler! Verweisquelle konnte nicht gefunden werden. illustrates one embodiment of provisioning CP/NC parameters in the UDM/UDR to an AMF and one or more SMFs.

In various embodiments, in response to there being multiple SCS/ASs using the same DNN/APN and/or PDU session, it may be useful to differentiate traffic from different applications. In such embodiments, the SCS/AS may include in a request to an SCEF/NEF traffic filter information (e.g., SCS/AS source IP address/port number). Moreover, the NEF may store the traffic filter information in an SM parameter and send the traffic filter to the SMF. Furthermore, the SMF may create and store the traffic filter information to determine the application and a corresponding UE behavior. In addition, the SCS/AS may also send to the network (e.g., NEF/SCEF which forwards the information to the UDM/UDR) information about a session continuity preference (e.g., SSC mode) or IP address preservation requirements for a connection between a UE and a network. Such session continuity information may be used in the SMF to determine the SSC mode to be applied to a PDU session and to select an appropriate UPF. Therefore, the UDM/UDR may classify and store such received session continuity information as SM information and send it to the SMF serving a corresponding PDU session. Further, in certain embodiments, an SCS/AS may signal and/or modify a DNAI which may be used to identify a user plane access to one or more DNs at which application server/content are deployed. This information may be used by the SMF to select an appropriate UPF to be close or co-located with a specific application server.

<FIG> illustrates another embodiment of communications <NUM> of remote unit <NUM> behavior parameters. Specifically, communications <NUM> between an AMF <NUM>, a first SMF <NUM>, a second SMF <NUM>, a UDM/UDR <NUM>, an NEF/SCEF <NUM>, a first SCS/AS <NUM>, and a second SCS/AS <NUM> are illustrated. As may be appreciated, any of the communications <NUM> described herein may be considered messages and/or parts of messages.

In some embodiments, a first communication <NUM> from the AMF <NUM> to the UDM/UDR <NUM> may include the AMF <NUM> performing a registration procedure and/or a provisioning procedure with the UDM/UDR <NUM>. In the first communication <NUM>, the UDM/UDR <NUM> may learn the that a UE is configured to use only a single service or single application (e.g., the UE transmission/reception behavior is determined by a single service/application), or the UDM/UDR <NUM> may learnt that the UE is configured to use multiple services or applications. The UDM/UDR <NUM> may use this knowledge during classifying <NUM> in which the UDM/UDR <NUM> determines how to categorize CP/NC parameters. In various embodiments, the UDM/UDR <NUM> may determine <NUM> that it is provisioned with a single application or single service.

In certain embodiments, a second communication <NUM> from the first SCS/AS <NUM> to the NEF/SCEF <NUM> may include the first SCS/AS <NUM> using various APIs to provide parameters specific to a given UE application (or the UE as such if a single application is used in the UE) to the NEF/SCEF <NUM> to facilitate efficient network configuration. Moreover, in various embodiments, a third communication <NUM> from the second SCS/AS <NUM> to the NEF/SCEF <NUM> may include the second SCS/AS <NUM> using various APIs to provide parameters specific to a given UE application to the NEF/SCEF <NUM> to facilitate efficient network configuration. In some embodiments, the first and second SCS/AS <NUM> and <NUM> may add, modify, and/or delete parameters provided to the network (e.g., provided to the NEF/SCEF <NUM>). As may be appreciated, the first and second SCS/AS <NUM> and <NUM> may use any existing APIs or other APIs. For example, the APIs may include: an API for CP parameter provisioning (e.g., any CP parameters, SCS/AS IP address, SCS/AS ID); an API for NC parameters; an API for an expected UE moving trajectory parameter. As described herein, any of the CP parameters, NC parameters, expected UE moving trajectory parameters, and/or other parameters may be considered CP/NC parameters.

In various embodiments, the NEF/SCEF <NUM> may discover <NUM> the UDM/UDR <NUM> based on a UE's GPSI which may in turn include an external ID or MSISDN.

In some embodiments, a fourth communication <NUM> from the NEF/SCEF <NUM> to the UDM/UDR <NUM> may include the NEF/SCEF <NUM> sending an update CP/NC parameter request message to the UDM/UDR <NUM> for delivering selected CP/NC parameters to one or more UEs. The CP/NC parameters may include a GPSI (which may be an external ID for a single UE or an external ID for a group of UEs), one or more SCEF reference IDs, an SCEF address, one or more CP/NC parameter sets, one or more validity times, one or more SCEF reference IDs for deletion, one or more SCS/AS IDs, and/or other parameters. In various embodiments, the fourth communication <NUM> may include a Nudm_ParameterProvision_Update having parameters such as: GPSI, SCS/AS ID, one or more NEF transaction reference IDs, one or more CP/NC parameter sets, one or more validity times, and so forth.

In certain embodiments, the UDM/UDR <NUM> may categorize <NUM> CP/NC parameters into at least MM parameters, SM parameters, and/or policy parameters. Moreover, the SM parameters may further be associated with a particular subscribed DNN and/or S-NSSAI. Furthermore, the UDM/UDR <NUM> may determine whether there are one or more applications on a UE (which may correspond to single or multiple SCS/ASs). In some embodiments, the UDM/UDR <NUM> uses a SCS/AS ID to determine corresponding DNN and/or S-NSSAI. In one embodiment, in response to a UE using a single service or application, the UDM/UDR <NUM> may decide to store all parameters as MM parameters and send them to the AMF <NUM>. In certain embodiments, in response to a UE using multiple services and/or applications, the UDM/UDR <NUM> may decide to categorize the CP/NC parameters into CP/NC MM parameters and CP/NC SM parameters. In various embodiments, if there are multiple SCS/ASs associated with a same DNN and/or S-NSSAI, a traffic filter (e.g., based on a SCS/AS's IP address) may be used to differentiate traffic from/to multiple SCS/ASs within the same DNN and/or S-NSSAI.

In various embodiments, all CP/NC parameter sets may be stored as SM parameters in a corresponding DNN and/or S-NSSAI subscription data. In such embodiments, the processing and or further classification of the CP/NC parameter sets may be performed at an SMF and the SMF may determine which parameters are forwarded to the AMF <NUM> as session parameter sets.

In certain embodiments, in response to there being no subscribed DNN for a UE (e.g., the UE uses only SMS or other messaging service without a need of a PDU session) or if a SCS/AS ID associated with CP/NC parameters received from the NEF/SCEF <NUM> does not correspond to a DNN, then the CP/NC parameter sets may be categorized as CP/NC MM parameters. In such embodiments, the UDM/UDR <NUM> stores the CP/NC parameter sets received from the NEF/SCEF <NUM> as CP/NC MM parameters and the UDM/UDR <NUM> sends the CP/NC MM parameters to the AMF <NUM>.

In some embodiments, in response to some parameters from SCS/AS or AF being explicitly indicated as mobility-related or access-related parameters (e.g., a UE trajectory), the UDM/UDR <NUM> may categorize those parameters as CP/NC MM parameters and send them to the AMF <NUM>.

In various embodiments, the UDM/UDR <NUM> may update <NUM> corresponding fields in a UE subscription (e.g., see Table <NUM>). In some embodiments, in response to CP/NC parameter sets being added, modified, and/or deleted in the UDM/UDR <NUM>, the UDM/UDR <NUM> may update: only the AMF <NUM> if the CP/NC parameters were MM related; only SMFs associated with the CP/NC SM parameters if the CP/NC parameters were SM related; or both the AMF <NUM> and one or more SMFs if the CP/NC parameters contained both MM and SM related parameters.

In certain embodiments, a fifth communication <NUM> from the UDM/UDR <NUM> to the NEF/SCEF <NUM> may include the UDM/UDR <NUM> sending an update CP parameter response to the NEF/SCEF <NUM>. In some embodiments, a sixth communication <NUM> from the NEF/SCEF <NUM> to the first SCS/AS <NUM> may include the NEF/SCEF <NUM> sending an update response to the first SCS/AS <NUM>. In various embodiments, a seventh communication <NUM> from the NEF/SCEF <NUM> to the second SCS/AS <NUM> may include the NEF/SCEF <NUM> sending an update response to the second SCS/AS <NUM>.

In certain embodiments, an eighth communication <NUM> from the UDM/UDR <NUM> to the AMF <NUM> may include the UDM/UDR <NUM> sending an update with MM parameters to the AMF <NUM>. In some embodiments, in the eighth communication <NUM>, the UDM/UDR <NUM> may initiate an insert subscription data procedure for each UE to send the CP/NC parameter sets with corresponding validity times, SCEF Reference IDs, and SCEF Reference IDs for deletion to the AMF <NUM>.

In various embodiments, the eighth communication <NUM> may include a Nudm_ SubscriberDataManagement parameter, a (SDM)_Notification, a SUPI, MM parameters, and so forth. In certain embodiments, the AMF <NUM> may use <NUM> the CP/NC MM parameters to derive expected UE behaviors. In some embodiments, the AMF <NUM> may send a periodic time parameter (e.g., as part of the CP parameter set) to a RAN as part of enhanced RRC inactive assistance information or the AMF <NUM> uses the periodic time to derive an expected UE activity behavior as part of the CN assisted RAN parameters tuning information. In such embodiments, the RAN may use this information (e.g. periodic time) to determine whether to configure an RRC inactive state for the UE. For example, in response to a periodic time being <NUM> seconds, the RAN may determine to configure the RRC inactive state to avoid increased signaling (e.g., perform a service request procedure every <NUM> seconds) and instead use a resume procedure. In some embodiments, the AMF <NUM> may use the MM parameters to determine RRC inactive assistance information or to enhance this information with other information (e.g., a periodic time parameter).

As may be appreciated, the AMF <NUM> may use <NUM> the CP/NC MM parameters to derive expected UE behaviors after the communication <NUM>. For example, the first SMF <NUM> may include a periodic time as a session parameter sent to the AMF <NUM> that the AMF <NUM> uses to derive expected UE behaviors.

In certain embodiments, a ninth communication <NUM> from the UDM/UDR <NUM> to the first SMF <NUM> may include the UDM/UDR <NUM>, in response to new or updated CP/NC parameters being provided to the UDM/UDR <NUM>, initiating an insert subscription data procedure for each UE to send CP/NC SM parameter sets with corresponding validity times, SCEF reference IDs, and/or SCEF reference IDs for deletion to the first SMF <NUM>. In various embodiments, the ninth communication <NUM> may include a Nudm_ SubscriberDataManagement parameter, a (SDM) _Notification, a SUPI, MM parameters, and so forth. In some embodiments, in response to the UDM/UDR <NUM> categorizing <NUM> the CP/NC parameter sets into CP/NC MM parameters and CP/NC SM parameters, the CP/NC SM parameters may contain a subset of the CP/NC parameters. In various embodiments, the UDM/UDR <NUM> stores whole CP/NC parameter sets as CP/NC SM parameters, and the CP/NC SM parameters are sent to the first SMF <NUM> as whole CP/NC parameter sets.

In some embodiments, a tenth communication <NUM> from the UDM/UDR <NUM> to the second SMF <NUM> may include the UDM/UDR <NUM>, in response to new or updated CP/NC parameters being provided to the UDM/UDR <NUM>, initiating an insert subscription data procedure for each UE to send CP/NC SM parameter sets with corresponding validity times, SCEF reference IDs, and/or SCEF reference IDs for deletion to the second SMF <NUM>. In various embodiments, the tenth communication <NUM> may include a Nudm_ SubscriberDataManagement parameter, a (SDM) _Notification, a SUPI, MM parameters, and so forth. In some embodiments, in response to the UDM/UDR <NUM> categorizing <NUM> the CP/NC parameter sets into CP/NC MM parameters and CP/NC SM parameters, the CP/NC SM parameters may contain a subset of the CP/NC parameters. In various embodiments, the UDM/UDR <NUM> stores whole CP/NC parameter sets as CP/NC SM parameters, and the CP/NC SM parameters are sent to the second SMF <NUM> as whole CP/NC parameter sets.

In various embodiments, the first and/or second SMFs <NUM> and <NUM> may process <NUM> the received CP/NC SM parameters, identify whether there are overlapping CP/NC SM parameter sets, and/or merge CP/NC SM parameter sets. In some embodiments, the first and/or second SMFs <NUM> and <NUM> may derive session parameters (e.g., MM or access control related parameters needed for operation of the AMF <NUM>) and signal the session parameters to the AMF <NUM> in an eleventh communication <NUM>. In certain embodiments, the first and/or second SMFs <NUM> and <NUM> store CP/NC SM parameters in a remote unit <NUM> context. In various embodiments, during a UP connection activation procedure, the first and/or second SMFs <NUM> and <NUM> may send SMF-assisted RAN information to an AN (e.g. NG-RAN node) within an N2 SM information message. For example, the first and/or second SMFs <NUM> and <NUM> may send a communication duration time, periodic time, expected number of uplink/downlink packets, and/or expected UE activity behavior to an NG-RAN node in order to assist the NG-RAN in deciding and/or configuring an RRC inactive state and/or configuring the connected state parameters of a remote unit <NUM>. As may be appreciated, the expected UE activity behavior may mean an expected pattern of a UE changes between CM-connected and CM-idle states. In one example, SMF-assisted RAN information may be used in the NG-RAN node to derive the expected UE activity behavior as described in TS <NUM>. In another example, the SMF derives the expected UE activity behavior and signals it to the NG-RAN node within the N2 SM information message during the activation of the UP connection for the PDU session. One reason to derive the expected UE activity behavior information in an SMF and signal it to the NG-RAN node is that the expected UE activity behavior may be applicable only when the associated PDU session (serving the associated application in the UE) is activated; otherwise if another PDU session is activated another expected UE activity behavior may be applicable, if determined in another corresponding SMF. The SMF may determine the expected UE activity behavior information considering the communication duration time and/or the periodic time from the CP/NC SM parameters.

In certain embodiments, the first and/or second SMFs <NUM> and <NUM> may use CP/NC SM parameters to configure the UPF. For example, the SMF can use the CP/NC parameter Suggested Number of Downlink Packets to configure a UPF with a number of downlink packets to buffer. In various embodiments, the first and/or second SMFs <NUM> and <NUM> may use SM parameters for internal processing. For example, the first and/or second SMFs <NUM> and <NUM> may use a communication duration time to determine to deactivate a UP connection after the communication duration time expires and/or the first and/or second SMFs <NUM> and <NUM> may perform a procedure CN-initiated selective deactivation of a UP connection of an existing PDU session.

In some embodiments, the first and/or second SMFs <NUM> and <NUM> may determine whether to use control plane or UP data delivery during PDU session establishment or to switch from control plane to UP delivery based on a parameter CP/UP delivery preference. This is described in detail in <FIG>.

In various embodiments, in response to there being multiple SCS/ASs associated with a same DNN/S-NSSAI, a traffic filter (e.g., based on SCS/AS's IP address) may be used to differentiate traffic from/to multiple SCS/ASs within the same DNN/S-NSSAI. For example, the first and/or second SMFs <NUM> and <NUM> may configure a UPF to: indicate to the first and/or second SMFs <NUM> and <NUM> the source IP address of the SCS/Ass; or differently forward packets depending on the source IP address of received downlink packets (e.g., data from one SCS/AS is forwarded over control plane NAS delivery and s data of another SCS/AS is forwarded over UP delivery). In certain embodiments, processing of CP/NC SM parameters in the first and/or second SMFs <NUM> and <NUM> may depend on policy rules received from a PCF, if available.

In some embodiments, the eleventh communication <NUM> from the first SMF <NUM> (and/or the second SMF <NUM>) to the AMF <NUM> may include the first SMF <NUM> informing the AMF <NUM> about session parameters (e.g., parameters derived from the CP/NC SM parameters as MM-relevant (or access control relevant) parameters for processing in the AMF <NUM>). As may be appreciated, the eleventh communication <NUM> may be performed either: during a successful PDU session establishment procedure in which an SMF sends a PDU session establishment accept message to a remote unit <NUM>; or an SMF may initiate a service operation by transmitting a message to the AMF <NUM> in response to SM parameters being updated from the UDM/UDR <NUM>. In certain embodiments, the eleventh communication may include: an existing service operation (e.g., Nsmf_PDUSession_SMContextStatusNotify (SUPI, PDU session ID, session parameters, etc.)) to notify the AMF <NUM> about new MM parameters; Nsmf_EventExposure_Notify (SUPI, PDU Session ID, Session parameters, etc.) transmitted to the AMF <NUM> (in response to the AMF <NUM> being previously subscribed); or a new service operations being specified.

In various embodiments, the eleventh communication <NUM> may include the AMF <NUM> receiving multiple session parameters sets for different PDU sessions (e.g., from different SMFs or from the same SMF). In some embodiments, the AMF <NUM> may store session parameters within a PDU session level context. In certain embodiments, based on an operator configuration or preference, the AMF <NUM> may merge session parameter sets associated with PDU sessions for which a UP Connection is to be activated. In other words, in response to a UP connection for a particular PDU session not being activated, corresponding session parameters may not be considered for RRC inactive assistance information, but may be considered for PSM mode (or MICO mode) or eDRX mode settings, for example.

In some embodiments, CP/NC MM parameters may include: a stationary indication; an expected UE moving trajectory; and/or a scheduled communication time. In various embodiments, CP/NC SM parameters may include: from CP parameters: a periodic time; a communication duration time; a scheduled communication time; and/or a SCS/AS IP address; and from NC parameters: a maximum Latency; a maximum response time and suggested number of downlink packets (buffering); and/or a CP/UP delivery preference.

In certain embodiments, session parameters (from an SMF to the AMF <NUM>) may include: a stationary indication; an expected UE moving trajectory; a periodic time; a scheduled communication time; a maximum latency; a maximum response time; and so forth. In some embodiments, CP/NC MM parameters and CP/NC SM parameters may include a validity time (e.g., if indicated by an SCS/AS) and the validity time may be provided an end consumer NF (e.g., an SMF and/or the AMF <NUM>). In other words, after expiration of a validity time, the UDM/UDR <NUM>, an SMF, and/or the AMF <NUM> may delete corresponding CP/NC parameters autonomously. As found herein, Table <NUM> shows an example how a UDM/UDR <NUM> may update stored UE subscription information in response to the UDM/UDR <NUM> categorizing <NUM> CP/NC parameter sets into CP/NC MM parameters and CP/NC SM parameters.

In some embodiments, based on CP/NC SM parameters received from the UDM/UDR <NUM>, an SMF may determine whether to apply UP or control plane delivery (or transmission) of data to a remote unit <NUM>. Such a decision at the SMF may be performed either: during PDU session establishment; or to later switch from control plane to UP delivery.

<FIG> illustrates a further embodiment of communications <NUM> of remote unit <NUM> behavior parameters. Specifically, communications <NUM> between a UE <NUM>, a RAN <NUM>, an AMF <NUM>, an SMF <NUM>, a UPF <NUM>, an NEF <NUM> (e.g., NEF/SCEF), and a UDM/UDR <NUM> are illustrated. As may be appreciated, any of the communications <NUM> described herein may be considered messages and/or parts of messages.

In some embodiments, an existing PDU session may be configured to transmit <NUM> uplink and downlink small data ("SD") over a control plane (e.g., over an NAS protocol between the SMF <NUM> and the UE <NUM> via the AMF <NUM>. In one embodiment, the SD may be transmitted over an N6 interface to an SCS/AS. In another embodiment, the SD may be transmitted over the NEF <NUM> and NBI API to an SCS/AS.

In certain embodiments, during PDU session establishment, the SMF <NUM> may determine to configure control plane delivery of data for a PDU session based on previously received (e.g., subscription or CP/NC SM parameters) information from the UDM/UDR <NUM>. For example, an SCS/AS/AF may have sent a parameter for control plane preference in the UDM/UDR <NUM> and the SMF <NUM> may receive this parameter from the UDM/UDR <NUM> during PDU session establishment. In such embodiments, the SMF <NUM> may use this parameter to determine to configure control plane delivery of data. In other words, the UE <NUM> may not need to indicate explicitly a control plane delivery method during PDU session establishment signaling.

In some embodiments, a first communication <NUM> from the UDM/UDR <NUM> to the SMF <NUM> may include the UDM/UDR <NUM> updating SM parameters in the SMF <NUM> in response to an SCS/AS having updated CP/NC parameters in the UDR/UDM <NUM>. For example, the SMF <NUM> may be updated with a new periodicity time, periodicity might be switched-off, and/or the SMF <NUM> may be updated with a new transmission duration time.

In certain embodiments, an SCS/AS/AF may signal and/or modify a preference for UP or control plane transmission by changing the value of the CP/UP preference parameter. For this purpose, either a CP/UP preference parameter is an SM parameter stored in the UDM/UDR <NUM>, or the CP/UP preference parameter is a parameter stored and/or managed by a PCF. In some embodiments, an SCS/AS may send to the NEF <NUM> a CP/UP preference indication which may then be forwarded to the UDM/UDR <NUM>. In such embodiments, the UDM/UDR <NUM> may process this CP/UP preference indication and the UDM/UDR <NUM> may determine to update a relevant PCF managing the UE's <NUM> policy rules. In various embodiments, an SCS/AS/AF may determine a CP/UP preference parameter value (e.g., UP preference value or control plane preference value, which may be encoded as e.g., "<NUM>", "<NUM>", or "<NUM>" bit map) based on an amount of data to transmit or based on a traffic pattern (the traffic pattern may be explicitly signaled to the network). Further, the SCS/AS/AF may maintain information from the MNO about the charging conditions or charging rules applied by the MNO when delivering data over control plane or over UP; and the SCS/AS/AF may consider this information together with the amount of data or traffic pattern when determining the value of the CP/UP delivery preference. In certain embodiments, in response to the SCS/AS/AF determining that a software and/or firmware update is needed, a same PDU session may be used to deliver both SD over control plane and software updates over a user plane in non-overlapping time spans. The CP/UP preference parameter may be sent from the SCS/AS/AF to the NEF <NUM> (i.e. over a T8 interface) either as part of the control plane parameter set, as part of the NC parameters, or as independent parameter.

In various embodiments, a second communication <NUM> from the AMF <NUM> to the SMF <NUM> may include the AMF <NUM> configuring a threshold value for a maximum amount of data (e.g., number of packets, number of bytes, etc.) to be transmitted over a control plane. The second communication <NUM> may occur either during PDU session establishment for control plane transmission or at a later time.

In certain embodiments, either based on triggers from the first communication <NUM> or the second communication <NUM>, or based on an internal configuration in the SMF <NUM>, the SMF <NUM> may determine <NUM> to switch a data transmission mechanism from control plane transmission to UP transmission. In some embodiments, a switch from control plane to UP transmission may be done to avoid an overload of the control plane (including the AMF <NUM> and SRBs) which may be meant for transmission of control plane messages.

In some embodiments, a third communication <NUM> from the SMF <NUM> to the AMF <NUM> may include the SMF <NUM> invoking a service operation. In such embodiments, the third communication <NUM> may include a Namf_Communication_N1N2MessageTransfer (e.g., SM context ID, N2 SM information (PDU session ID, N3 tunnel information, QFls, QoS profiles, session-AMBR), N1 SM container (PDU session modification command (PDU session ID, UP indication, QoS rules, QoS rule operation, session-AMBR)), and so forth). In certain embodiments, N2 SM information may be similar to N2 SM information used during UP connection activation (e.g., it contains N3 tunnel info, PDU session ID, and QoS-related information). In various embodiments, in response to the data (e.g. SD) being received/sent via the NEF <NUM>, the SMF <NUM> may select and/or configure the UPF <NUM>.

In some embodiments, in response to the UE <NUM> being in an idle state (e.g., CM-IDLE state), the AMF <NUM> may decide whether to page the UE <NUM> based on an ATC status. In various embodiments, the AMF <NUM> may update and/or store the UE <NUM> context based on a Namf_Communication _N1N2MessageTransfer, in response to the UE <NUM> not being reachable.

In certain embodiments, a fourth communication <NUM> from the AMF <NUM> to the RAN <NUM> may include the AMF <NUM> sending an N2 PDU session request (e.g., N2 SM information received from the SMF <NUM>, NAS message (e.g., PDU session ID, N1 SM container (PDU session modification command))) message to the RAN <NUM>.

In various embodiments, a fifth communication <NUM> between the RAN <NUM> and the UE <NUM> may include the RAN <NUM> issuing AN specific signaling exchange with the UE <NUM> that is related to information received from the SMF <NUM>. For example, in embodiments with a 3GPP RAN, an RRC connection reconfiguration may take place with the UE <NUM> establishing RAN <NUM> resources related to QoS Rules for a PDU session request received in the fourth communication <NUM>.

In some embodiments, a sixth communication <NUM> from the RAN <NUM> to the AMF <NUM> may include the RAN <NUM> transmitting an N2 session response to the AMF <NUM>. In certain embodiments, a seventh communication <NUM> from the AMF <NUM> to the SMF <NUM> may include the AMF <NUM> forwarding N2 SM information and/or an N1 container to the SMF <NUM>. In various embodiments, an eighth communication <NUM> from the SMF <NUM> to the AMF <NUM> and a ninth communication <NUM> from the AMF <NUM> to the SMF <NUM> may include communications for updating the UE <NUM> context to reconfigure from control plane delivery to UP delivery.

In some embodiments, a tenth communication <NUM> from the SMF <NUM> to the UPF <NUM> and an eleventh communication <NUM> from the UPF <NUM> to the SMF <NUM> may include communications for N4 modification and/or creation. In certain embodiments, communications <NUM> may be used for SD transmission over UP.

In various embodiments, the AMF <NUM> may send "RRC inactive assistance information" to be used in the RAN <NUM> to determine whether the UE <NUM> may be transitioned to an RRC inactive state. However, the RAN <NUM> behavior may not depend on a used and/or activated UP connection.

In certain embodiments, the SMF <NUM> influences NG-RAN behavior based on an activated UP connection. There are several options to perform this. In one embodiment, as described in <FIG>, the SMF <NUM> may update the UE's <NUM> PDU session context in the AMF <NUM> with session parameters which may be used in the AMF <NUM> to determine "RRC inactive assistance information" which is extended with periodic time and/or communication duration time. In another embodiment, the SMF <NUM> includes SMF assisted RAN information in N2 SM information sent to an NG-RAN node as described in <FIG>.

<FIG> illustrates an additional embodiment of communications <NUM> of remote unit <NUM> behavior parameters. Specifically, communications <NUM> between a UE <NUM>, a RAN <NUM>, an AMF <NUM>, an SMF <NUM>, a UPF <NUM>, and an NEF <NUM> are illustrated. As may be appreciated, any of the communications <NUM> described herein may be considered messages and/or parts of messages.

In some embodiments, SD of a PDU session may be configured to be transmitted <NUM> over a control plane. In such embodiments, in response to CP transmission being configured, data may be delivered over an NAS protocol between the SMF <NUM> and the UE <NUM>. The data may be received by the SMF <NUM> either over an N6 interface from the UPF <NUM> or from the NEF <NUM>.

In certain embodiments, SD of the PDU session may be configured to be transmitted <NUM> over a user plane. In such embodiments, the data may be received by the UPF <NUM> either over an N6 interface or from the SMF <NUM> via the NEF <NUM>. In various embodiments, the UE <NUM> may be in an idle state (e.g., CM-IDLE state) at some point.

In some embodiments, the SMF <NUM> stores <NUM> CP/NC SM parameters (e.g., received from a UDM/UDR as described in relation to <FIG> or received from the AMF <NUM>). Based on CP/NC SM parameters the SMF <NUM> may determine <NUM> SMF assisted RAN information to be sent to the RAN <NUM>. In certain embodiments, a first communication <NUM> from the UE <NUM> to the SMF <NUM> may include the UE <NUM> transmitting a service request to the SMF <NUM> via the AMF <NUM>. In various embodiments, a second communication <NUM> from the UPF <NUM> to the SMF <NUM> may include the UPF <NUM> transmitting DL data to the SMF <NUM>. In some embodiments, due to mobile originated communication (e.g., the first communication <NUM>) or due to mobile terminated communication (e.g., the second communication <NUM>), a user plane connection for a PDU session may be activated.

In certain embodiments, a third communication <NUM> from the SMF <NUM> to the AMF <NUM> may include the SMF <NUM> initiating signaling or service operation. In such embodiments, the service operation may be initiated using Namf_Communication_N1N2MessageTransfer (e.g., N2 SM information (SMF assisted RAN information (expected UE activity behavior, communication duration, periodic time, and/or expected number of uplink/downlink packets, etc.), N1 SM container, etc.)). In various embodiments, the SMF <NUM> may include new parameters within an S2 SM information container (e.g., expected UE activity behavior, a communication duration, expected number of uplink/downlink packets, and/or a periodic time, etc.). In such embodiments, the new parameters included in the N2 SM information container from the SMF <NUM> may be in general referred as SMF assisted RAN information including further parameters. The SMF <NUM> may determine the expected UE activity behavior information considering a communication duration time and/or a periodic time from the CP/NC SM parameters, but also other parameters gained from statistics gathered internally in the network. The SMF <NUM> may determine an expected number of uplink/downlink packets parameter based on the CP/NC SM parameters, for example. As may be appreciated, the parameter expected number of uplink/downlink packets may include separate parameters (e.g., expected number of uplink packets parameter and/or expected number of downlink packets parameter), or may be coded as a parameter with multiple values (e.g., [<NUM>, <NUM>] meaning <NUM> uplink packets and <NUM> downlink packets, or [<NUM>, <NUM>] meaning <NUM> uplink packets and <NUM> downlink packets).

In some embodiments, a fourth communication <NUM>, a fifth communication <NUM>, a sixth communication <NUM>, and a seventh communication <NUM> may be substantially similar to communication as described in TS <NUM> clause <NUM>. <NUM> steps <NUM> - <NUM>.

In various embodiments, the RAN <NUM>, after receiving SMF assisted RAN information from the SMF <NUM> (including e.g., parameters such as communication duration, expected UE activity behavior, or periodic time), may use these parameters to configure or reconfigure <NUM> a radio connection with the UE. For example, based on a periodic time, the RAN <NUM> may determine whether to keep the UE <NUM> in a connected state (e.g., RRC connected state), to configure an inactive state (e.g., RRC inactive state), or to trigger an idle state (e.g., trigger an RRC idle state via releasing an RRC connection or triggering release of AN resources procedure). In another example, in response to the RAN <NUM> determining to configure an inactive state, the RAN <NUM> may determine based on communication duration parameters whether to deactivate the inactive state or to trigger release of AN resources procedure after the communication duration time expires. In another example, the RAN <NUM> may receive an expected UE activity behavior from the SMF <NUM> and use this information to determine a transition pattern between RRC connected, RRC idle, and/or RRC inactive states.

In various embodiments, the AMF <NUM> may provide the following RRC inactive assistance information to the RAN <NUM>: UE specific DRX values; a registration area provided to the UE; a periodic registration update timer; in response to the AMF <NUM> enabling a MICO mode for the UE <NUM>, an indication that the UE <NUM> is in MICO mode; and/or information from the UE <NUM> permanent identifier, as defined in TS <NUM>, that allows the RAN <NUM> to calculate the UE's RAN paging occasions.

In some embodiments, the SMF <NUM> during an UP connection activation procedure may also provide SMF assisted RAN information from the SMF <NUM> which is specific to an activated PDU session. In certain embodiments, in response to the RAN <NUM> having multiple activated PDU sessions simultaneously and the RAN <NUM> receives SMF assisted RAN information from the SMF <NUM> for multiple PDU sessions, the RAN <NUM> may merge the multiple SMF assisted RAN information from the SMF <NUM> and determine to configure the radio Uu interface correspondingly. The RAN <NUM> may also receive RAN information from the AMF <NUM> (e.g., RRC inactive assistance information) and SMF assisted RAN information from one or more SMFs <NUM>. In such cases the RAN <NUM> may merge the RAN information of the same type (e.g., if there are multiple communication duration parameters, the RAN <NUM> may take the larger value to configure a UE inactivity time, for example) or the RAN <NUM> may use different information types for different purposes. For example, the RAN <NUM> may use RRC inactive assistance information from the AMF <NUM> to determine an RRC inactive state configuration, but the RAN <NUM> may use SMF assisted RAN information from the SMF <NUM> (e.g., expected UE activity behavior, expected number of uplink/downlink packets, and/or communication duration) to determine a time to initiate transition from RRC connected to RRC inactive state, and/or to initiate transition from RRC connected to RRC idle state. In various embodiments, an RRC inactive state may be configured by the RAN <NUM> in response to there being a PDU session using control plane transmission of data (e.g., without having user plane resources activated). In some embodiments, an RRC inactive state may be configured during a time in which there is a mixture of a PDU session using a control plane transmission and a PDU session using the UP transmission. In certain embodiment, if the UE state is CM-connected and RRC inactive, and due to the activation of a UP connection of a PDU session, the RAN <NUM>, based on received SMF assisted RAN information, may decide to change from RRC inactive state to RRC connected state. In yet another embodiment, based on the received expected number of uplink/downlink packets (e.g., as part of SMF assisted RAN information) the RAN <NUM> may determine whether the data to be transmitted is small data (e.g., just a single packet) or bigger size data; or the RAN <NUM> may determine whether uplink and/or downlink communication has been completed based on a number of packets transmitted in an uplink and/or a downlink direction. If the RAN <NUM> determines that uplink and/or downlink communication has been completed, the RAN <NUM> may decide to initiate release of AN resources by sending an RRC connection release message with or without an indication for resume identity, and, respectively, whether to initiate N2 signaling transmission to the AMF <NUM> to request release of the AN resources. The presence of a resume identity indication may mean transition from an RRC connected state to an RRC inactive state. The non-presence of a resume identity indication may mean transition from an RRC connected state to an RRC idle state. In certain embodiments, the parameter periodic time (e.g., as part of the SMF assisted RAN information) may be used in the RAN <NUM> to determine whether the transmission of data is frequent or infrequent; and, consequently, to determine which RRC state for the UE would be the most appropriate in order to save UE power consumption and/or signaling transmitted to the CN due to RRC state transitions.

In certain embodiments, CP/NC parameter sets may not be processed and classified by a UDM/UDR into CP/NC MM parameters and CP/NC SM parameters, but the CP/NC parameter sets may be stored as CP/NC MM parameters. In one embodiment, the UMD/UDR may determine and store, if available, a DNN and/or S-NSSAI corresponding to each CP/NC MM parameter set. In such an embodiment, CP/NC MM parameter sets may be sent to the AMF <NUM> together with associated DNN and/or S-NSSAI. In some embodiments, the AMF <NUM> stores CP/NC MM parameter sets and associated DNN and/or S-NSSAI. In various embodiments, in response to the UE <NUM> initiating a PDU session establishment procedure, if the AMF <NUM> determines that a DNN and/or S-NSSAI included in the N1 interface signaling from the UE <NUM> for PDU session establishment is related to a stored CP/NC MM parameter set, the AMF <NUM> may send the associated CP/NC MM parameter sets or a portion thereof related to session management to the SMF <NUM> in an N11 message from the AMF <NUM> to the SMF <NUM>. In other words, processing and classifying CP/NC MM parameter sets as SM parameters may be done in the AMF <NUM> and the SM parameters may be sent to the SMF <NUM>. For example, a modified service operation from the AMF <NUM> to the SMF <NUM> may be as follows: Nsmf_PDUSession_CreateSMContext Request (SUPI, DNN, S-NSSAIs, PDU session ID, AMF ID, request type, PCF ID, N1 SM container (PDU session establishment request), CP/NC SM parameters). In some embodiments, CP/NC SM parameters are SM parameters determined by the AMF <NUM> as session-relevant parameters.

In various embodiments, in response to a PDU session already being established to a particular DNN and/or S-NSSAI and the AMF <NUM> receives a new and/or updated CP/NC MM parameter set, the AMF <NUM> may initiate, via communication to the SMF <NUM>, a service operation (e.g., Nsmf_PDUSession_UpdateSMContext Request (SUPI, PDU session ID, CP/NC SM parameters, request type, cause, etc.)). In such embodiments, the service operation message may be insert as new or updated SM parameters in the SMF <NUM>.

In some embodiments, CP/NC SM parameters sent from the AMF <NUM> to the SMF <NUM> may be: a periodic time; a communication duration time; an SCS/AS IP address; a suggested number of downlink packets (buffering); maximum latency; a CP/UP delivery preference; DNAI; and/or SSC mode preference, etc. In certain embodiments, the SMF <NUM> may use CP/NC SM parameters as described herein in relation to <FIG>Fehler! Verweisquelle konnte nicht gefunden werden. , <FIG>, and/or <FIG>. In various embodiments, the SMF <NUM> may not need to determine and signal session parameters to the AMF <NUM>.

<FIG> is a schematic flow chart diagram illustrating one example of a method <NUM> for determining remote unit <NUM> behavior parameters. In some examples, the method <NUM> is performed by an apparatus, such as the network unit <NUM>. In certain examples the method <NUM> may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

The method <NUM> may include receiving <NUM> a message including parameters associated with an application in a remote unit. In various embodiments, the method <NUM> includes determining <NUM> a first set of parameters including a first portion of the parameters, wherein each parameter of the first set of parameters corresponds to a remote unit behavior. In certain embodiments, the method <NUM> includes determining <NUM> a second set of parameters including a second portion of the parameters, wherein each parameter of the second set of parameters corresponds to a service behavior. In some embodiments, the method <NUM> includes associating <NUM> the second set of parameters with a data network name, a single network slice selection assistance information, or a combination thereof.

In one example, receiving the message includes receiving one or more messages, and each of the one or more messages contains a validity time for parameters included therein. In a further embodiment, receiving the message includes receive the message from a network exposure function. In certain embodiments, the method <NUM> includes transmitting the first set of parameters to an access and mobility management function. In various embodiments, the access and mobility management function determines how to configure the remote unit, a base station, or a combination thereof, based on the first set of parameters.

In some examples, the method <NUM> includes transmitting the second set of parameters to a session management function. In various embodiments, the session management function configures one or more network functions or radio entities using the second set of parameters, and the one or more network functions are configured with information specific to a protocol data unit session, a traffic flow, or a combination thereof. In one embodiment, the parameters include information indicating a preference for either a control plane transmission or a user plane transmission. In various embodiments, the parameters include information indicating an internet protocol address, a port number, or a combination thereof corresponding to a service server, an application server, or a combination thereof. In certain examples, the parameters include information indicating an identifier corresponding to a service server, an application server, an application, or some combination thereof.

<FIG> is a schematic flow chart diagram illustrating one example of a method <NUM> for determining remote unit <NUM> behavior parameters. In some examples, the method <NUM> is performed by an apparatus, such as the network unit <NUM>. In certain examples, the method <NUM> may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

The method <NUM> may include receiving <NUM> a message including a third set of parameters. In various examples, the method <NUM> includes determining <NUM> a fourth set of parameters including a first portion of the third set of parameters, wherein each parameter of the fourth set of parameters corresponds to remote unit session behavior. In certain example, the method <NUM> includes determining <NUM> a fifth set of parameters including a second portion of the third set of parameters, wherein each parameter of the fifth set of parameters corresponds to a service behavior.

In one example, the method <NUM> includes transmitting the fourth set of parameters to an access and mobility management function. In a further example, the method <NUM> includes determining configuration information for a user plane function based on the fifth set of parameters, and transmitting the configuration information to the user plane function. In certain examples, the method <NUM> includes determining configuration information for a base station based on the fifth set of parameters. In some examples, the method <NUM> includes transmitting the configuration information to the base station. In certain examples, the third set of parameters includes a first set of parameters corresponding to a remote unit behavior. In various examples, the third set of parameters includes a second set of parameters corresponding to a service behavior. In some examples, the third set of parameters includes a first set of parameters corresponding to a remote unit behavior and a second set of parameters corresponding to a service behavior.

Claim 1:
A method performed by a Unified Data Management or User Data Repository, the method for determining remote unit behavior parameters, the method comprising:
receiving from an Application Function or a Network Exposure Function, a message comprising parameters associated with an application in a remote unit;
determining a first set of parameters comprising a first portion of the parameters, wherein each parameter of the first set of parameters corresponds to a remote unit behavior;
transmitting the first set of parameters to an access and mobility management function;
determining a second set of parameters comprising a second portion of the parameters, wherein each parameter of the second set of parameters corresponds to an application behavior;
associating the second set of parameters with a data network name, a single network slice selection assistance information, or a combination thereof; and
transmitting the second set of parameters to a session management function.