WO2022159725A1 - Federated identity management in fifth generation (5g) system - Google Patents

Federated identity management in fifth generation (5g) system Download PDF

Info

Publication number
WO2022159725A1
WO2022159725A1 PCT/US2022/013338 US2022013338W WO2022159725A1 WO 2022159725 A1 WO2022159725 A1 WO 2022159725A1 US 2022013338 W US2022013338 W US 2022013338W WO 2022159725 A1 WO2022159725 A1 WO 2022159725A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
user
pdu session
smf
request
Prior art date
Application number
PCT/US2022/013338
Other languages
French (fr)
Inventor
Ching-Yu Liao
Original Assignee
Intel Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corporation filed Critical Intel Corporation
Publication of WO2022159725A1 publication Critical patent/WO2022159725A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/186—Processing of subscriber group data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0894—Policy-based network configuration management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles

Definitions

  • Various embodiments generally may relate to the field of wireless communications.
  • some embodiments may relate to federated identity management in fifth generation (5G) systems.
  • 5G fifth generation
  • Various embodiments generally may relate to the field of wireless communications.
  • Figure 1 A depicts an illustrative diagram of a residential network, in accordance with various embodiments.
  • FIG. IB depicts an illustrative diagram of a personal internet of things (loT) network (PIN), in accordance with various embodiments.
  • LoT personal internet of things
  • FIG. 2 depicts an example diagram of federated identity management in a fifth generation (5G) network, in accordance with various embodiments.
  • Figure 3 illustrates example Nnef_ParameterProvision_Create / Nnef_ ParameterProvision Update / Nnef ParameterProvision Delete request/response operations, in accordance with various embodiments.
  • FIG. 4 schematically illustrates example service specific information provisioning, in accordance with various embodiments.
  • FIG. 5 illustrates an example user equipment (UE) Configuration Update procedure for transparent UE Policy delivery, in accordance with various embodiments.
  • UE user equipment
  • Figure 6 illustrates an example non-roaming reference architecture of policy and charging control framework for the 5G System (service based representation), in accordance with various embodiments.
  • Figure 7 illustrates an example non-roaming reference architecture of policy and charging control framework for the 5G System (reference point representation), in accordance with various embodiments.
  • Figure 8 illustrates an example relationship between user, identities, identifiers and attributes, in accordance with various embodiments.
  • Figure 9 illustrates an example UE Configuration Update procedure for access and mobility management related parameters, in accordance with various embodiments.
  • Figure 10 illustrates an example UE Configuration Update procedure for transparent UE Policy delivery, in accordance with various embodiments.
  • FIG. 11 illustrates example service-specific information provisioning, in accordance with various embodiments.
  • FIGS 12A-C illustrate an example registration procedure, in accordance with various embodiments.
  • FIG. 13 illustrates an example protocol data unit (PDU) Session Establishment authentication/authorization by a 5G direct network authentication, authorization, and accounting (DN-AAA) server, in accordance with various embodiments.
  • PDU protocol data unit
  • DN-AAA 5G direct network authentication, authorization, and accounting
  • Figures 14A-B illustrate an example UE -requested PDU Session Establishment for nonroaming and roaming with local breakout, in accordance with various embodiments.
  • Figure 15 illustrates an example technique related to identity management in fifth generation systems, in accordance with various embodiments.
  • Figure 16 illustrates an alternative example technique related to identity management in fifth generation systems, in accordance with various embodiments.
  • Figure 17 schematically illustrates a wireless network in accordance with various embodiments.
  • Figure 18 schematically illustrates components of a wireless network in accordance with various embodiments.
  • Figure 19 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein.
  • a machine-readable or computer-readable medium e.g., a non-transitory machine-readable storage medium
  • the PIN network is a set of Personal loT devices configured to communicate between themselves and with a user equipment (UE) (e.g. smartphone, residential gateway etc) using direct device connections.
  • UE user equipment
  • Objectives of this study may include enabling 5GS support of Personal loT networks with one or more of the following aspects:
  • Onboarding devices with operator managed credentials within the Personal loT Network from a user/UE (e.g., smartphone) or via a 5G network (e.g. a public land mobile network (PLMN)).
  • a user/UE e.g., smartphone
  • a 5G network e.g. a public land mobile network (PLMN)
  • non-3GPP devices e.g. media server, printer, a non-access stratum (NAS) server, etc.
  • NAS non-access stratum
  • These non-3GPP devices may usually be configured behind a wireless gateway, but there may some security risks found in such settings due to port forwarding (e.g., with universal plug and play (UPnP) enabled) and unsecure connectivity provided by the wireless gateway for these non-3GPP devices at PIN/Residential network.
  • port forwarding e.g., with universal plug and play (UPnP) enabled
  • unsecure connectivity provided by the wireless gateway for these non-3GPP devices at PIN/Residential network.
  • an evolved residential gateway (eRG) or gateway UE with 5G capability may be used for providing 5G network connectivity to the connected non-3GPP devices or small base stations (e.g. PRAS) behind the eRG/gateway UE. Additionally, it may be desirable for the eRG/gateway UE to ensure the services provided by the non-3GPP devices or small base stations are visible in the 5G network for the authorized users from anywhere in the world to access these authorized services.
  • eRG evolved residential gateway
  • PRAS small base stations
  • Various embodiments herein may be related to on the 3GPP TS 22.101 clause 26a, and use cases in the Rel-16 study on user-centric identifiers and authentication, as indicated in TR22.904.
  • Such use cases may be when the operator acts as identity provider for users using 3GPP devices, in which the user can be individual human user, using a UE with a certain subscription, or an application running on or connecting via a UE or a device (“thing”) behind a gateway UE.
  • Identifying distinguished user identities of the user (provided by some external party or by the operator) in the operator network may enable an operator to provide an enhanced user experience and optimized performance as well as to offer services to devices that are not part of a 3 GPP network.
  • the network settings can be adapted, and services offered to users according to their needs, independent of the subscription that is used to establish the connection.
  • the operator may be able to take additional information from the network into account to provide a higher level of security for the authentication of a user.
  • the concept of identity federation may be similar to that used in data center deployments for improving security for users accessing authorized services and allowing flexible deployment scenarios, e.g. a company with many organizations located in different areas.
  • An example of such as concept may be as is described in 3GPP TR 22.858 as follows:
  • IdP Identity Provider
  • IdPs An Identity Provider (IdP) is an entity that creates and manages identities of users and authenticates user to other applications that rely on the IdP. IdPs are responsible for asserting digital identities with claims for the rlying applications to consume.
  • a Service Provider is an entity that provides Web Services. SPs may not authenticate users by themselves but rely on IdPs for user authentication.
  • Identity Federation is the process of delegating an individual’s or entity’s authentication responsibility to a trusted external party.
  • Each partner in federation plays the role of either an IdP or a SP.
  • identity federation an IdP vouches fo rthe identity of the users, and an SP provides service to the users.
  • the SP delegates the authentication to the IdP. This is called federation.
  • identity federation For identity federation to take place, the SP must trust the authentication ability of the IdP.
  • the trusted identity providers can be on-premise federation services, corporate directories, social identity providers like Google®, Facebook®, Twitter®, etc.
  • embodiments herein relate to a framework to enable support of federated identity management (FIM) in the operator’s 5G network for different data network domains in the clouds, PIN, and residential network connected with the 5G network.
  • FIM federated identity management
  • the operator acting as an identity provider may enhance the security of the PIN or residential network connected with 5G network by user authentication, service authorization, and/or access control.
  • existing 5G networks may not be built to permit Federated identity management for different types of data network domains, e.g. in the cloud, PIN, or residential, which may require authentication on individual domains such that domain Y cannot access services in domain X.
  • Embodiments of this disclosure may relate to one or more of the following solutions: Solution 1 : Operator as identifier provider for federated identity management Solution 2: User identity of associated entity of a trusted UE/eRG
  • Solution 3 Primary authentication for associated entity of a trusted UE/eRG
  • Solution 4 5GS with FIM for supporting secondary authentication/authorization/access control Solutions: eRG capabilities for supporting service access to non-3GPP device or PRAS
  • Solution6 Authorized UE configuration for the available service domains of PINs.
  • Legacy techniques may include secondary authentication/authorization for UEs to access services of the data network domain in the cloud.
  • there may be a lack of solutions to allow an operator to act as identity provider for authenticating the associated entity of the UE/eRG in different data network domains of PIN/residential network.
  • legacy solutions of secondary authentication/authorization may not be able to differentiate the associated users using the UE.
  • the solutions of user authentication/authorization/access control can be applied to different data network domains of cloud services, services provided personal loT network, and/or residential network.
  • Evolved Residential Gateway a gateway between the public operator network (fixed/mobile/cable) and a customer premises network within a residence, office or shop.
  • Premises Radio Access Station a base station installed at a customer premises network primarily for use within a residence, office, or shop.
  • loT device a type of UE that is dedicated for a set of specific use cases or services, and which is allowed to make use of certain features restricted to this type of UEs.
  • an loT device may be optimized for the specific needs of services and application being executed (e.g. smart home/city, smart utilities, e-Health and smart wearables). Some loT devices may not intended for human type communications.
  • PIN Personal loT Network
  • PIN Element the basic component making up a PIN-User’s Personal loT Network.
  • the PIN Element maybe an loT device, terminal equipment (TE), mobile termination (MT), mobile equipment (ME), a “thing” as may be described in sub clause 26a.1 of 3GPP TS 22.101, or a UE.
  • PIN Element with Gateway Capability a system or device that may act as a gateway that provides access to and from the public operator’s network (fixed/mobile/cable) and a PIN.
  • PIN Element with Management Capability A PIN Element with PIN management Capability that has capability to manage the PIN.
  • PIN direct connection the connection between two PIN elements without any 3 GPP RAN or core network entities positioned between the two PIN elements. In some use cases or embodiments, a PIN direct connection may internally be relayed amongst other PIN elements or other entities (such as a wireless local area network (WLAN) access point).
  • WLAN wireless local area network
  • Direct device connection the connection between two UEs without a network entity in the middle.
  • Direct network connection One mode of network connection, where there is no relay UE between a UE and the 5G network.
  • Indirect network connection one mode of network connection, where there is a relay UE between a UE and the 5G network.
  • a “thing” may be associated entity of the UE/eRG including human users, a non-3GPP device (not a UE), applications running on the UE/eRG or connected to the UE/eRG, etc.
  • the network in a residential environment may be called a Customer Premise network (CPN), in which the network provider provides 5G connectivity service via a CPN to its customer in the residential environment.
  • CPN Customer Premise network
  • the 5G system may be deployed as a PLMN or a SNPN by a network operator such as a Mobile Network Operator or a Non-public network operator.
  • a network operator such as a Mobile Network Operator or a Non-public network operator.
  • Embodiments herein are not limited to the type of network. While embodiments may be described with respect to a PLMN, embodiments may apply to a SNPN or another type of network.
  • Figures la-lb show the illustrative diagrams for the residential network and PIN, respectively.
  • the eRG connected to the 5G network may provide connectivity for a PRAS or a non-3GPP device using a fixed/cable/wireless connection.
  • the PRAS may further provide connections for UEs.
  • Figure lb the PIN Element with Gateway and management Capability connected to the 5G network may provide connectivity to a PIN Element which may be a UE or non-3GPP device.
  • 3GPP TS 22.261 clause 26a may address the use case of an operator acting as identity provider for identifying associated entity of a 3GPP UE by a user identity.
  • the user identity may associate to one or more user profiles in which each profile is identified by a user identifier, and respective user profiles contain attributes that characterize the respective users.
  • a “user” may be a logical concept for an associated entity of a 3 GPP UE. Examples may include human users, non-3GPP devices, applications, etc.
  • An associated entity (user) to the UE may be a human user that uses the UE, a non-3GPP device connected with the UE, and/or an application/ service running on the UE or connected with the UE, in which the associated entity (user) may be identified by a user identity provided by the operator based on the information configured by the UE subscriber.
  • Solution 1 Operator as identifier provider for federated identity management
  • Embodiments herein relate to federated identity management in a 5G system as shown in Figure 2.
  • Figure 2 depicts an example diagram of federated identity management in a fifth generation (5G) network, in accordance with various embodiments.
  • 5G fifth generation
  • An operator may act as an IdP responsible for user authentication of services provided in different data network domains: o
  • For Data network domain#! in the cloud the operator may have a trust relationship with service provider 1 (SP1) and service provider 2 (SP2).
  • For Data network domain#2 in the cloud the operator may have a trust relationship with the domain owner, which acts as an identity provider (denoted as IdP2) within the domain#2 and has a trust relationship with service provider 3 (SP3) and service provider 4 (SP4).
  • IdP2 identity provider
  • SP3 service provider 3
  • SP4 service provider 4
  • the eRG may act as a gateway to interconnect two networks and relay the traffic between a residential network and the 5G network.
  • the eRG with 3 GPP capabilities may have trust relationship with 5G network.
  • the eRG may play a role of an IdP3 to manage associated entities in the data network domain of the residential network (not shown in the figure) and the trust may be assumed when the eRG and PRAS/non-3GPP device get connected using 3GPP or non-3GPP based standards.
  • the associated entity of the eRG may include a PRAS and a non- 3GPP device (e.g. media server, smart TV, game console, thermostat, smart sprinkler, etc.), which are connected with the eRG via 3 GPP or non-3GPP technologies (e.g. wifi, Bluetooth, wireline), in which each associated entity is regarded as a data network domain in the residential network and the eRG acts as a data network proxy.
  • a non- 3GPP device e.g. media server, smart TV, game console, thermostat, smart sprinkler, etc.
  • 3 GPP 3 GPP
  • non-3GPP technologies e.g. wifi, Bluetooth, wireline
  • the authenticated/authorized eRG subscriber may be able to add the information of an associated entity of the eRG to the 5G network, in which the associated entity is regarded as a user with a user identity associated to the eRG subscription.
  • the operator authenticates the user identity of the associated non-3GPP device(s) or PRAS(s) of the eRG, the trust may be further established between the non-3GPP device/PRAS and eRG.
  • the next level of trust may be further established between the non- 3 GPP device/PRAS and their associated entities, e.g. UEs connected to the PRAS, or the applications running on the non- 3GPP device or connected to it, as long as the operator is able to continue to authenticate the identity of these associated entities (at the second level) of trusted entities (at the first level).
  • their associated entities e.g. UEs connected to the PRAS, or the applications running on the non- 3GPP device or connected to it.
  • the PIN can also be in the CPN of residential environment.
  • respective ones of the associated entity may be viewed as one or more data networks in data network domain#3.
  • data network domain#3 only one data network is presented in data network domain#3 for simplicity.
  • the subdomain of the data network may include the PRAS, PIN, non-3GPP device.
  • each associated entity may represent one data network domain.
  • the eRG routes the traffic based on the data network domain name, e.g. DNN.
  • the subscriber may be able to configure a human user, which may have a user identity in the 5G network as an associated entity of the UE, using authorized UEs to use services/applications with corresponding user identities provided in different data network domains connected with 5G networks via authorized 5G capable devices (UE or eRG), e.g. data network domain#!, #2, #3, and #4.
  • UE or eRG authorized 5G capable devices
  • the human user using an authenticated/authorized UE can access authorized services provided by different authorized data network domains, which may improve signaling overhead, delay, and smooth user experiences without compromising the security.
  • the UE with 3 GPP capabilities may have a trust relationship with the 5G network.
  • the authenticated/authorized UE subscriber may be able to add the information of an associated entity of the UE to the 5G network, in which the associated entity is regarded as a user with user identity associated to the UE subscription.
  • the operator authenticates the user identity of the associated entities of the UE (e.g. non-3GPP devices, human users, and applications operated on the UE or connected to the UEs)
  • the trust can be further established between associated entity (user) and the UE.
  • Solution 2 User identity of associated entity of a trusted UE/eRG
  • the associated entity of the UE/eRG may include one or more of: for data network domain in the clouds: the associated entity may include the cloud service users. for data network domain in the residential network, PIN: the associated entity may include human user, non-3GPP device/PRAS behind the UE/eRG, applications running on the UE/eRG or connected to UE/eRG, etc.
  • Solution 2.1 Service for a user of a data network domain in the cloud
  • the service user information is provisioned based on the procedure in 3GPP TS 23.502: ⁇ 4.15.6.2, network exposure function (NEF) service operations information flow (to a network function (NF), for a UE and/or a UE group) with the following modifications as shown below:
  • NEF network exposure function
  • the AF receives and validate service user information from service providers.
  • the AF request contains at least one of the following parameters sets of “Service Users of the Data Network Domain parameters for FIM”: o DNN (data network name) o Subdomain name associated to DNN o S-NSSAI (network slice of the PDU session) o User Identity for the associated entity of the UE as service users in data network domain o
  • specific service settings and parameters of the associated entity with User Identity including network parameters (e.g. QoS parameters), IMS service (e.g. MMTEL supplementary services) and operator deployed service chain settings, specific network resources (e.g., network slice).
  • network parameters e.g. QoS parameters
  • IMS service e.g. MMTEL supplementary services
  • operator deployed service chain settings e.g., specific network resources
  • DNN data network name
  • Subdomain name associated to DNN may be the network slice of the PDU session
  • S-NSSAI single network slice selection assistance information
  • Figure 3 illustrates example Nnef_ParameterProvision_Create / Nnef_ ParameterProvision Update / Nnef ParameterProvision Delete request/response operations, in accordance with various embodiments.
  • the detailed message flow of Figure 3 may be as follows:
  • Step 0. NF subscribes to UDM notifications of UE and/or Group Subscription data updates. o the AF receives and validate service user information from service providers in a specific data network domain.
  • Step 1 The AF provides one or more parameter(s) to be created or updated in a Nnef ParameterProvision Create or Nnef ParameterProvision Update or Nnef ParameterProvision Delete Request to the NEF.
  • the GPSI identifies the UE of the associated entity and the Transaction Reference ID identifies the transaction request between NEF and AF.
  • NEF assigns a Transaction Reference ID to the Nnef ParameterProvision Create request. NEF checks whether the requestor is allowed to perform the requested service operation by checking requestor's identifier (e.g. AF ID).
  • requestor's identifier e.g. AF ID
  • the payload of the AF request for Nnef ParameterProvision Update Request message includes one or more of the following “Service Users of the Data Network Domain parameters for FIM”: o DNN (data network name) o User Identity of the associated entity with the UE, which is regarded as service users in data network domain o
  • Step 2 If the AF is authorized by the NEF to provision the parameters, the NEF requests to create, update and store, or delete the provisioned parameters as part of the subscriber data via Nudm ParameterProvision Create, Nudm ParameterProvision Update or Nudm ParameterProvision Delete Request message, the message includes the provisioned data and NEF reference ID.
  • Step 6 If the requester is not authorised to provision data, then the NEF continues in Step 6 indicating the reason to failure in Nnef ParameterProvision Create/Update/Delete Response message. Step 7 does not apply in this case.
  • Step 3 UDM may read from UDR, by means of Nudr DM Query, corresponding subscription information in order to validate required data updates and authorize these changes for this subscriber or Group for the corresponding AF.
  • Step 4 If the AF is authorised by the UDM to provision the parameters for this subscriber, the UDM resolves the GPSI to SUPI, and requests to create, update or delete the provisioned parameters as part of the subscriber data via Nudr DM Create/Update/Delete Request message, the message includes the provisioned data.
  • UDR stores the provisioned data as part of the UE and/or Group subscription data and responds with Nudr_DM_Create/Update/Delete Response message.
  • Step 5 the reason to failure in Nudm ParameterProvision Update Response message and Step 7 is not executed.
  • the UDM classifies the received parameters into access and mobility function (AMF)- Associated, session maangement function (SMF)-Associated parameters.
  • AMF access and mobility function
  • SMF session maangement function
  • the UDM may use the AF ID received from the NEF in Step 2 to relate the received parameter with a particular subscribed DNN and/or S-NSSAI.
  • the UDM stores the SMF- Associated parameters under corresponding Session Management Subscription data type.
  • Each parameter or parameter set may be associated with a validity time.
  • the validity time is stored at the UDM/UDR and in each of the NFs, to which parameters are provisioned (e.g. in AMF or SMF).
  • each node Upon expiration of the validity time, each node deletes the parameters autonomously without explicit signaling.
  • Step 5 UDM responds the request with Nudm ParameterProvision Create/Update/Delete Response. If the procedure failed, the cause value indicates the reason.
  • Step 6 NEF responds the request with Nnef ParameterProvision Create/Update/Delete Response. If the procedure failed, the cause value indicates the reason.
  • Step 7 [This Step may occur only after successful Step 4] UDM notifies the subscribed Network Function (e.g., SMF) of the updated UE and/or Group subscription data via Nudm_SDM_Notification Notify message. If the NF is SMF, the UDM performs Nudm SDM Notification (SUPI or Internal Group Identifier, SMF Associated parameter set, DNN/S-NSSAI, etc.) service operation.
  • SMF Subscribedm_SDM_Notification Notify message.
  • Nudm SDM Notification SUPI or Internal Group Identifier, SMF Associated parameter set, DNN/S-NSSAI, etc.
  • the SMF stores the received SMF -Associated parameters and associates them with a PDU Session based on the DNN and S-NSSAI included in the message from UDM.
  • the SMF identifies whether there are overlapping parameter set(s) in the Service Users of the Data Network Domain parameters for FIM and merges the parameter set(s), if necessary.
  • the SMF may use the SMF- Associated parameters as follows:
  • the SMF may determine whether to perform secondary authentication/authorization with DN-AAA during PDU session establishment request procedure.
  • the UDM (in Step 3) can also update the corresponding UDR data via Nudr_DM_Create/Delete as appropriate.
  • Solution 2.2 Service for a user of a data network domain in the PIN/residential environment
  • non-3GPP device or PRAS may be manually added and configured by the UE subscriber or eRG subscriber at operator’s network.
  • non-3GPP device refers to a device that does not have 3GPP network capabilities and/or is not registered to a 3GPP network.
  • a “3GPP” device refers to a device that has 3GPP network capabilities and/or is registered to a 3 GPP network.
  • the operator network creates the user identity for the associated entity, e.g. non-3GPP device or PRAS, of the UE/eRG subscription.
  • Each user identity may further include one or more user profiles, each identified by a user identifier, containing corresponding attributes.
  • one or more user profiles may be further created for different network slices with corresponding attributes, e.g., frequency bands, service/slice type, allowed application, etc.
  • the operator may also add some attributes based on operator policies for PRAS.
  • the configuration of the user profile that includes a user identifier and corresponding attributes may be used for the service authorization and access control.
  • a northbound API between an Application function and the 5G network may be used to automate the process for adding an associated entity (non-3GPP device or PRAS) of the UE/eRG subscriber as follows:
  • the UE or eRG When the UE or eRG receives the upper layer request, e.g. a human user scans the QR code of the new associate entity (PRAS, PIN device) which connects to the UE or eRG, to add the new associated entity with the UE subscriber or eRG subscriber, the UE or eRG connects to the application server of the associated entity, e.g. based on the QR code.
  • PRAS new associate entity
  • PIN device PIN device
  • the application server of the associated entity uses AF API of AF to send AF request (using northbound API) to the 5G network for creating associated entity as a user based on the UE subscription.
  • Embodiments may use the procedure for service specific parameter provisioning as an example such that the AF using Nnef ServiceParameter service or a new AF request message to request creating an associated entity as a user and providing service specific parameters to the PLMN and the UE, as in 3GPP TS 23.502 Figure 4.15.6.7-1.
  • Figure 4 depicts an example of such a technique from 3GPP TS 23.502, Figure 4.15.6.7-1.
  • Figure 4 Figure 4 schematically illustrates example service specific information provisioning, in accordance with various embodiments.
  • the process flow of Figure 4 may include the following modification:
  • Step 1 (Creation of the AF Request) may be modified such that the AF request sent to the NEF may include at least one of the following information as below:
  • User Description is the information to identify an associated entity the User information are applied to.
  • the User Description in the AF request can contain at least one of the following information:
  • - user type specify the type of the associated entity including human user, non-3GPP device, PRAS
  • the UDR configures a User ID in the response message.
  • one or more user profiles for this associated entity containing corresponding user identifiers and attributes: o User identifier that identified the user profile, o List of authorized UEs (identified by their subscription and device identifiers) for the service/application, o capabilities the used UEs support for authentication, o information regarding authentication/authorization policies required by different services and slices to authenticate a user for access to these services or slices.
  • 5G network parameters e.g. QoS parameters
  • IMS service e.g.
  • Data network parameters of the associated entity include information of local IP address domain configured by the UE/eRG.
  • the 5G network e.g. PCF, allocates at least one of the following information for identifying the data network domain of the associated entity: the DNN, subdomain name, and S-NSSAI. All these data network parameters can be used together to identify a data network service in the PIN/residential environment (CPN).
  • the associated entity may be dependent on the UE/eRG subscription.
  • the UE subscription may include the Federated Identity Management services for user centric management and authentication provided by the operator.
  • Service Description is the information to identify a service the Service Parameters are applied to.
  • the Service Description in the AF request can be represented by the combination of DNN and S-NSSAI, an AF-Service-Identifier or an application identifier.
  • Service Parameters are the service specific information which needs to be provisioned in the Network and delivered to the UE in order to support the service identified by the Service Description.
  • Target UE(s) or a group of UEs indicate the UE(s) who the Service Parameters shall be delivered to.
  • Individual UEs can be identified by GPSI, or an IP address/Prefix or a MAC address.
  • the PCF may perform one or more of the following: creating the one or more user profiles of the associated entity. allocating at least one of the following information for identifying the data network domain of the associated entity: the DNN, subdomain name, and S-NSSAI. All these data network parameters can be used together to identify a data network service in the PIN/residential environment (CPN). configuring user policy containing information of user identifiers, data network configuration (e.g.
  • a NAS procedure may be used to automate the process for adding an associated entity (e.g., a non-3GPP device or a PRAS) of the UE/eRG subscriber as follows:
  • the UE or eRG When the UE or eRG receives the upper layer request, e.g. a user scan the QR code of the new associate entity (PRAS, PIN device), to add the new associated entity with the UE subscriber or eRG subscriber, the UE or eRG initiates a registration request procedure by indicating the following information in NAS message: o
  • a new registration type indicates the associated entity registration o
  • a new IE includes the associated entity type, including human users, non- 3 GPP device, PRAS.
  • a new IE includes the User ID or user defined user Identity of the associated entity
  • the User ID can be allocated by the 5G network and user defined user Identity is configured by the associated entity/eRG/UE. If user defined user Identity is provided, the PCF/UDR configures and includes a User ID in the response message. o A new IE includes the container of the user profile of the associated entity, e g-
  • specific service settings and parameters of the associated entity with User Identity including network parameters (e.g. QoS parameters), IMS service (e.g. MMTEL supplementary services) and operator deployed service chain settings, specific network resources (e.g., network slice).
  • network parameters e.g. QoS parameters
  • IMS service e.g. MMTEL supplementary services
  • operator deployed service chain settings e.g., specific network resources
  • the AMF When the AMF receives the NAS message, it requests the associated PCF of the UE/eRG to create a user profile of the associated entity at UDR.
  • a User ID of the associated entity is created by PCF/UDR if a user defined user identity is provided in the registration request message.
  • the AMF includes the following information for the new added associated entity:
  • ⁇ User Identity type indication human user, PIN device, PRAS, applications;
  • the PCF may decide to update UE policy of the UE/eRG subscriber using the following procedure in 3GPP TS23.502, Figure 4.2.4.3-1 (depicted at Figure 5) with the following new information in the UE/eRG policy for the associated entity:
  • ⁇ User Identity type indication human user, PIN device, PRAS, applications;
  • the UE/eRG stores the UE/eRG policy. Specifically for PRAS, the eRG can further deliver the related configuration of the one or more user profile to the PRAS over the connection between the eRG or PRAS, in which the information can be delivered using N3 protocol (eRG is regarded as associated UPF).
  • N3 protocol eRG is regarded as associated UPF
  • Solution 3 Primary authentication for associated entity of a trusted UE/eRG
  • the user identity of the associated entity may be created at the 5G network.
  • This solution may further provide a solution to register an associated entity of a UE/eRG, wherein the associated entity includes the non-3GPP devices, and PRAS.
  • the UE/eRG has been registered with the network to get authorized to receive 5G services and has stored NAS security context.
  • a UE/eRG receiving a upper layer request may perform registration procedures for the associated entity, as indicated in 3GPP TS 23.502 clause 4.2.2.2, with the following modifications:
  • the registration request message indicates the following: o a new registration type indicates associated entity registration o UE/eRG ID, e g. SUPI/SUCI or 5G-GUTI or PEI o User ID of the associated entity o one or more user credentials of the associated entity for the UE/eRG, including user identifier, password, public key, token, certificate, etc., where in the user identifier can be used to locate the stored user profile of the associated entity.
  • a new registration type indicates associated entity registration o UE/eRG ID, e g. SUPI/SUCI or 5G-GUTI or PEI o
  • User ID of the associated entity o one or more user credentials of the associated entity for the UE/eRG, including user identifier, password, public key, token, certificate, etc., where in the user identifier can be used to locate the stored user profile of the associated entity.
  • Step 9 based on the registration type indicated as associated entity registration, the AMF checks the UE authentication status, e.g. how long does the UE registered, the location of the UE, etc., and determines the confidence level of the UE registration status which may require to quarry NWDAF for the analytic info. o If the confidence level of the UE registration is accepted, the AMF initiates the authentication requests with AUSF for the associated entity of the UE by indicating UE/eRG ID, User ID of the associated entity, and one or more user credentials of the associated entity. The AUSF may retrieve the user profile from UDR via UDM/PCF based on the user identifier and performs authentication of the user identity based on the user credentials stored in user profiles. In the case of the PCF, the AMF provides information of associated PCF. o If the confidence level of the UE registration is not accepted, the AMF may send registration rejection message with proper rejection cause or indication of re-registration of the UE.
  • the AMF may send registration rejection message with proper rejection cause or
  • Solution 4 5GS with FIM for supporting secondary authentication/authorization/access control
  • the user authentication, service authorization and access control may be performed for a different data network domains in a similar manner.
  • Step 1 the request message in includes one of the following information: o UE ID o DNN, S-NSSAI o User ID of the associated entity o Credentials for accessing the services, e.g. user identifier, security keys, public keys, token, certificates, etc.
  • Step 6 PDU session authentication/authorization: o
  • the SMF determines the confidence level of the UE registration status, which may require to quarry NWDAF for the analytic info. o If User ID and user identifier of the associated entity is included in the request message, the SMF checks with the PCF for the corresponding user profile and determines the policies for the secondary authentication/authorization policies.
  • the secondary authentication/authorization policies may indicate one or more of the following: o 5G network for authentication and authorization o 5G network for authentication only o DN-AAA for authentication and authorization
  • the following elements for secondary authentication/authorization procedure may be performed if the confidence level of the UE registration is accepted:
  • the SMF initiates the secondary authentication procedure towards DN-AAA based on 3GPP TS 23.502 clause 4.3.2.3 (e.g., as may be shown in Figure 13) with the following modification: o Step 2:
  • Casel If the authentication/authorization policy indicates 5G for authentication/authorization or 5Gfor authentication only, the SMF request AUSF for authentication/authorization directly or via AMF by indicating authentication type set as secondary authentication/authorization or authentication only, User ID, and user credentials.
  • the AUSF may retrieve the user profile from UDR via UDM/PCF based on the user identifier and performs authentication of the user identity based on the user credentials stored in user profiles.
  • the AMF provides information of associated PCF.
  • the SMF sends Authentication/Authorization request to DN-AAA indicating DN authorization only, User ID, user identifier, and confidence level of the associated UE registration.
  • the DN-AAA performs user authorization and replies the result to the SMF.
  • Solution 5 eRG capabilities for supporting service access to non-3GPP device or PRAS
  • the eRG/UE acting as a gateway and a 5G network may need to support the following capabilities: eRG/gatway UE with 5G capabilities supports NAT (network address translation), and Data network proxy
  • the 5G network manages the updates of the IP address of eRG/gateway UE and the data network domain of the associated entities.
  • eRG/gateway UE subscription includes: o Federated Identity services of 5G network for handling user identities, user profiles, user authentication, service authorization, access control, etc.
  • eRG/gateway UE capabilities include: o Data network proxy o DN-AAA capabilities eRG/ gateway UE ’ s regi strati on procedure : o the eRG/gateway UE indicates its eRG/gateway UE capabilities in the registration request message o the eRG/gateway UE uses PDU session modification request procedure to update DN-AAA address information at eRG by indicating a new IE in the request message.
  • the eRG/gateway UE When a new non-3GPP device or PRAS is discovered/connected to eRG/gateway UE, the eRG/gateway UE performs registration procedure to register the non-3GPP device or PRAS with user identities, the 5G network allocates DNN information for identifying the data network domain of the associated entity for the eRG/gateway UE.
  • eRG/gateway UE transfers traffic of multiple data network domains for PIN and residential network o
  • the eRG/gateway UE may determine to use the same or different PDU session for transferring traffic of multiple data network domains for PIN and residential. o If different PDU sessions are used for transporting user plane data for different data network domain of associated entity, the eRG/gateway UE uses PDU session request/modification procedure to provide/update the DNN information of the data network domain for the associated entities.
  • the eRG/gateway UE indicates one or more DNN(s) of data network domain(s) for the associated entity(es) in the new IE in the PDU session request/modification request message.
  • the SMF stores the mapping information between the PDU session ID and one or more DNN(s) of the data network domains for the associated entity of the eRG/gateway UE.
  • eRG/gateway UE acts as DN proxy o
  • the eRG/gateway UE sends a PDU session establishment request indicating the reliable connection for DN proxy and this PDU session is used for any DN related control plane traffic, e.g. authentication request/response messages.
  • DN proxy e.g. authentication request/response messages
  • the SMF stores and maintains the mapping information between eRG/gateway UE ID and eRG/gateway UE address for DN proxy.
  • the SMF updates the IP address of the eRG/gateway UE as DN proxy whenever there are changes.
  • the eRG/gateway UE has DDNS-like client to update the change of the IP address with DDNS (dynamic data domain name server) in the 5G network.
  • the 5G network provides DDNS configuration information, e.g. IP address of the DDNS server and credential settings, in the registration accept message, PDU session establishment accept message, or in the UE configuration update procedure.
  • Solution 6 Authorized UE configuration for the available service domains of PINs.
  • the authorized UE may be configured with information of the data network domains via UE configuration update procedure, as indicated in 3GPP TS 23.502, Figure 4.2.4.3-1 (which may be depicted at Figure 5 herein).
  • UE configuration update procedure as indicated in 3GPP TS 23.502, Figure 4.2.4.3-1 (which may be depicted at Figure 5 herein).
  • Such information may be related to the UE Configuration Update procedure for transparent UE Policy delivery, which is triggered by PCF for updating the following set of information for an authorized data network domain.
  • the information may include: Authorized DNN(s) of the data network domains, e.g. PIN, Residential network Allowed S-NSSA(s) of each authorized DNN
  • the embodiments related to associating a new entity of a gateway UE/PIN Element with a Gateway Capability/eRG subscriber may be applied to non-3GPP devices as new associated entity, e.g. smart home devices (smart plug, smart watch, smart garage door, etc) and PRAS.
  • PIN Element The related use case and service flows for on boarding non-3GPP device (PIN Element) are as follows:
  • Step 1 User-X (human user) has subscribed to PIN services from MNOa.
  • Step 2 User-X installs a smart plug (with only Bluetooth or WLAN connectivity) and wants to add it to his PIN based on the subscription for the PIN.
  • User-X scans a bar code of the plug which guides the smartphone/UE (as gateway UE/PIN Element with Gateway Capability) to a webpage of an application server.
  • Step 3 Then the application server requests 5G network via AF to on board the PIN Element, i.e. smart plug.
  • the 5G network Based on the on boarding request from the UE, including the UE ID, PIN ID (if available) and the smart plug configuration information, the 5G network creates User Identity for the PIN Element and associated it with the UE.
  • the PIN Element sends the on boarding request to the application server is regarded as offering the permission to add the new associated PIN Element.
  • the 5G network creates a PIN with a PIN ID.
  • the corresponding PIN configuration is stored, which may be associated to the PIN Element with Gateway Capability.
  • the 5G network sends a request message asking for the permission from the second PIN Element. With the permission, the 5G network continues this step 3. Otherwise, the 5G network rejects the process to add the PIN Element and replies rejection cause in the response message to the PIN Element requesting for on boarding the PIN Element. o
  • the permission request is sent via NAS message or user plane traffic to the second PIN Element.
  • Step 4 The User Profile of the PIN Element is also created (as indicated in the previous solutions) and stored at the MNOa with configuration information provided by the PIN Element via the UE.
  • the User Profile contains the User Identifier and the configuration of the PIN Element.
  • o User Identifier o Specific configuration settings and parameters, e.g. active/inactive time, number of accesses, etc.
  • o Authorized communication methods e.g. direct network connection, direct device connection, PIN direct connection (e.g. Bluetooth, WLAN, wireline).
  • Authentication/authorization policy and access restriction policy to access the PIN Element or application running on the PIN Element.
  • the PIN Element can have one or more User Profile (each is identified by different User Identifier). For example, for the same PIN Element, it can connect via two gateways with PIN Element Gateway Capability, e.g. UE or eRG. When the PIN Element connects to different gateways, it can apply different User Profiles associated to its User Identity. Step 5 : if PIN ID is not available, the 5G network creates a PIN ID to uniquely identify the PIN and return the allocated PIN ID to the PIN Element with Gateway Capability for the PIN in the notification message responding to the on boarding request from the AF.
  • Step 6 The application server sends the notification message (including PIN ID, identity of the PIN Element, and authorization of the communications between the PIN Element with Gateway Capability and the PIN Element) to the PIN Element with Gateway Capability which requested to on boarding its associated non-3GPP device.
  • Step 7 User-X gets a notification on his UE that a new PIN Element, a plug, has been added. In the meantime, User-X can see the status of the new added smart plug via the webpage and the UE.
  • Step 8 the PIN Element with Gateway Capability stores the configuration (e.g. the PIN Element Identity or identifier) of the PIN Element and the PIN ID.
  • the configuration e.g. the PIN Element Identity or identifier
  • Step 9 when the PIN Element connects to different gateways, it can apply different User Profiles associated to its User Identity and indicates User identifier and the corresponding credentials in the registration request message.
  • Step 10 the 5G network authenticates the non-3GPP device/PIN Element based on User profile associated to the user identifier and the credentials indicated in the registration request message.
  • the PIN ID is replaced with a PRAS ID
  • the configuration information of the PRAS includes the PRAS radio capabilities (WLAN, wireline or 3 GPP radio capabilities and network capabilities.
  • the PRAS supports 3GPP radio capabilities, it contains applicable settings, e.g. the carrier frequencies, and IAB capability (via eRG or gNB as donor IAB).
  • the PRAS supports 3 GPP network capabilities, it contains applicable settings, e.g. NAS for connecting to N3IWF.
  • one or more of the following service requirements may be present in the context of Solution 7, above.
  • the 5G network shall be able to create and manage a PIN.
  • a PIN Element with Gateway Capability in a PIN shall be able to on board a PIN Element connected to it to the 5G network.
  • the 5G network shall support suitable APIs for the third party to provide configuration information of a PIN Element connected to a PIN Element with Gateway Capability in a PIN.
  • the 5G network shall be able to create an identity that can uniquely identify the PIN Element and is associated to the PIN Element with Gateway Capability.
  • the 5G network shall be able to authenticate PIN Elements within the PIN and manage the communication with other PIN Elements using PIN direct connection.
  • the 5G network shall be able to configure and authorize a PIN Element with Gateway Capability with PIN Element with Management Capability which can manage and configure management and configuration data of the PIN locally.
  • TSXY.ABC may refer to the 3GPP TS XY.ABC.
  • TRXY.ABC may refer to the 3GPP TR XY.ABC.
  • Figures 6 and 7, copied from TS 23.503, illustrate examples of the overall architecture for policy and charging framework in the 5G system in both service-based and reference point representation.
  • Figure 5 may correspond to 3GPP TS 23.503 Figure 5.2.1-1, and illustrate an example non-roaming reference architecture of policy and charging control framework for the 5G System (service based representation), in accordance with various embodiments.
  • Figure 7 may correspond to 3GPP TS 23.503 Figure 5.2.1-la, and illustrate an example non-roaming reference architecture of policy and charging control framework for the 5G System (reference point representation), in accordance with various embodiments.
  • entity In the context of identity management something outside a system that needs to be identified in the system is referred to as “entity”. In 3GPP such an entity is called a user. A user is not necessarily a person, it could also be an application or a device (“thing”).
  • the entity is uniquely represented by an identity in the system.
  • the identity can dependent on the role of the entity in the system (e.g. which kind of service is used for which purpose).
  • a user can have several user identities - e.g. one user identity representing the professional role of the (human) user and another one representing some aspects of her private life. There is a 1 :n relation between user and user identity.
  • the user to be identified could be an individual human user, using a UE with a certain subscription, or an application running on or connecting via a UE, or a device (“thing”) behind a gateway UE.
  • Figure 8 illustrates an example relationship between user, identities, identifiers and attributes, in accordance with various embodiments.
  • a user identity is associated with some pieces of information, which are generally called attributes.
  • attributes One special form of attributes are identifiers.
  • the relation between identity and identifier is l:n.
  • Each user identity may be identified in the system by one or more user identifiers.
  • An identifier could take the form of an NAI, email address or some number [UUID], could be permanent (comparable to the IMSI), or temporary (comparable to the TMSI).
  • “User Identity” relates to an individual human user
  • a user might choose to use their company email address when registering and using services (access to web portals) that they needs for their work.
  • services access to web portals
  • the email addresses are the user identifiers that identify the different identities of the user for certain web services.
  • attributes could contain information about the date of birth of a user, the private address, the company name and address, job title etc. Attributes that are not identifiers may be associated with more than one identity, e.g. date of birth might be relevant in the professional as well as in the private context. One identity typically is associated with several attributes.
  • An identity provider creates, manages and stores this information in one place, authenticates a selected user identity (e.g. verifies a claimed user identity) for a service and provides the result and necessary attributes to the service.
  • UE configuration may be updated by the network at any time using UE Configuration Update procedure.
  • UE configuration includes:
  • Access and Mobility Management related parameters decided and provided by the AMF. This includes the Configured NSSAI and its mapping to the Subscribed S-NSSAIs, the Allowed NSSAI and its mapping to Subscribed S-NSSAIs, the Service Gap time and the list of Rejected NS SAIs if the UE Configuration Update procedure is triggered by the AMF after Network Slice-Specific Authentication and Authorization of S-NSSAIs. If the UE and the AMF support RACS, this may also include a PLMN-assigned UE Radio Capability ID or alternatively a PLMN-assigned UE Radio Capability ID deletion indication.
  • the AMF indicates this to the UE explicitly.
  • Figure 9 illustrates an example UE Configuration Update procedure for access and mobility management related parameters, in accordance with various embodiments. Specifically, Figure 9 may be similar to TS23.502, Figure 4.2.4.2-1.
  • This procedure is initiated when the PCF wants to update UE access selection and PDU Session selection related policy information (e.g. UE policy) in the UE configuration.
  • PDU Session selection related policy information e.g. UE policy
  • the V-PCF is not involved and the role of the H-PCF is performed by the PCF.
  • the V-PCF interacts with the AMF and the H-PCF interacts with the V- PCF.
  • This clause describes the procedures for enabling the AF to provide service specific parameters to 5G system via NEF.
  • the AF may issue requests on behalf of applications not owned by the PLMN serving the UE.
  • the AF In the case of architecture without CAPIF support, the AF is locally configured with the API termination points for the service. In the case of architecture with CAPIF support, the AF obtains the service API information from the CAPIF core function via the Availability of service APIs event notification or Service Discover Response as specified in TS23.222.
  • the AF request sent to the NEF contains the information as below:
  • Service Description is the information to identify a service the Service Parameters are applied to.
  • the Service Description in the AF request can be represented by the combination of DNN and S-NSSAI, an AF-Service-Identifier or an application identifier.
  • Service Parameters are the service specific information which needs to be provisioned in the Network and delivered to the UE in order to support the service identified by the Service Description.
  • Target UE(s) or a group of UEs (optional)
  • Target UE(s) or a group of UEs indicate the UE(s) who the Service Parameters shall be delivered to.
  • Individual UEs can be identified by GPSI, or an IP address/Prefix or a MAC address.
  • Groups of UEs can be identified by an External Group Identifiers as defined in TS 23.682 [23],
  • the Service Parameters shall be delived to any UEs using the service identified by the Service Description.
  • the NEF authorizes the AF request received from the AF and stores the information in the UDR as "Application Data”.
  • the Service Parameters are delivered to the targeted UE by the PCF when the UE is reachable.
  • Figure 4 (which may be similar to TS23.502 Figure 4.15.6.7-1) shows an example procedure for service specific parameter provisioning.
  • the AF uses Nnef ServiceParameter service to provide the service specific parameters to the PLMN and the UE.
  • the AF invokes an Nnef ServiceParameter Create service operation.
  • the AF invokes an Nnef ServiceParameter Update or Nnef ServiceParameter Delete service operation together with the corresponding Transaction Reference ID which was provided to the AF in Nnef_ServiceParameter_Create response message.
  • the AF sends its request to the NEF.
  • the NEF authorizes the AF request.
  • the NEF performs the following mappings:
  • Nnef ServiceParameter Create (in the case of Nnef ServiceParameter Create): The NEF assigns a Transaction Reference ID to the Nnef ServiceParameter Create request.
  • the NEF stores the AF request information in the UDR as the "Application Data" (Data Subset setting to "Service specific information") together with the assigned Transaction Reference ID.
  • Nnef ServiceParameter delete The NEF deletes the AF request information from the UDR.
  • the NEF responds to the AF.
  • the response message includes the assigned Transaction Reference ID.
  • the PCF(s) receive(s) a Nudr DM Notify notification of data change from the UDR.
  • PCF does not have to subscribe for each UE the application specific information, e.g. if PCF has already received the application specific information for a group of UE or for a DNN by a subscription of other UE.
  • the same application specific information is delivered to every UE in a group or a DNN.
  • the PCF initiates UE Policy delivery as specified in clause 4.2.4.3.
  • This service is for allowing external party to provision of service specific parameters which can be used for the UE in 5GS.
  • the detailed information is described in clause 4.15.6.7.
  • Service Descriptor e.g. the combination of DNN and S-NSSAI, an AF-Service-Identifier or an application identifier
  • Service Parameters and Target UE identifiers e.g. the address (IP or Ethernet) of the UE if available, GPSI if available, External Group Identifier if available
  • Service Descriptor e.g. the combination of DNN and S-NSSAI, an AF- Service-Identifier or an application identifier
  • Transaction Reference ID e.g. the combination of DNN and S-NSSAI, an AF- Service-Identifier or an application identifier
  • Service Parameters and Target UE identifiers e.g. the address (IP or Ethernet) of the UE if available, GPSI if available, External Group Identifier if available).
  • the consumer deletes service specific parameters from the UDR via the NEF.
  • Service Descriptor e.g. the combination of DNN and S-NSSAI, an AF- Service-Identifier or an application identifier
  • Transaction Reference ID e.g. the combination of DNN and S-NSSAI, an AF- Service-Identifier or an application identifier
  • Target UE identifiers e.g. the address (IP or Ethernet) of the UE if available, GPSI if available, External Group Identifier if available).
  • the consumer retrieves service specific parameters in the UDR via the NEF.
  • Service Descriptor e.g. the combination of DNN and S-NSSAI, an AF-Service-Identifier or an application identifier.
  • Service Parameters and Target UE identifiers e.g. the address (IP or Ethernet) of the UE if available, GPSI if available, External Group Identifier if available).
  • TS23.502 4,15.6.2 NEF service operations information flow (to NF, for UE and UE group)
  • Figure 3 illustrates example Nnef_ParameterProvision_Create / Nnef_ ParameterProvision Update / Nnef ParameterProvision Delete request/response operations, in accordance with various embodiments.
  • Figure 3 may be similar to Figure 4.15.6.2-1 of TS23.502, and include the following elements:
  • NF subscribes to UDM notifications of UE and/or Group Subscription data updates.
  • the AF may subscribe to NWDAF via NEF in order to learn the UE mobility analytics and/or UE Communication analytics for a UE or group of UEs by applying the procedure specified in TS 23.288 [50] clause 6.1.1.2.
  • the Analytics Id is set to any of the values specified in TS 23.288 [50] clause 6.7.1.
  • AF validates the received data and derives any of the Expected UE behaviour parameters defined in clause 4.15.6.3 for a UE or group of UEs.
  • the AF provides one or more parameter(s) to be created or updated in a Nnef ParameterProvision Create or Nnef ParameterProvision Update or Nnef ParameterProvision Delete Request to the NEF.
  • the GPSI identifies the UE and the Transaction Reference ID identifies the transaction request between NEF and AF.
  • Nnef ParameterProvision Create For the case of Nnef ParameterProvision Create, The NEF assigns a Transaction Reference ID to the Nnef ParameterProvision Create request.
  • - NEF checks whether the requestor is allowed to perform the requested service operation by checking requestor's identifier (e.g. AF ID).
  • requestor's identifier e.g. AF ID
  • the External Group ID identifies the 5G VN Group.
  • the payload of the Nnef ParameterProvision Update Request includes one or more of the following parameters: o Expected UE Behaviour parameters (see clause 4.15.6.3), or o Network Configuration parameters (see clause 4.15.6.3a), or o External Group Id and 5G VN group data (e.g. 5G-VN configuration parameters) (see clause 4.15.6.3b), or o 5G VN group membership management parameters (see clause 4.15.6.3c) o Location Privacy Indication parameters of the "LCS privacy" Data Subset of the Subscription Data (see clause 5.2.3.3.1 and TS 23.273 [51] clause 7.1)
  • the AF may request to delete 5G VN configuration by sending Nnef ParameterProvision Delete to the NEF.
  • the NEF requests to create, update and store, or delete the provisioned parameters as part of the subscriber data via Nudm ParameterProvision Create, Nudm ParameterProvision Update or
  • Nudm ParameterProvision Delete Request message the message includes the provisioned data and NEF reference ID.
  • Step 6 If the requester is not authorised to provision data, then the NEF continues in step 6 indicating the reason to failure in Nnef ParameterProvision Create/Update/Delete Response message. Step 7 of this process flow does not apply in this case.
  • the NEF can directly forward the external parameter to the UDR via Nudr DM Update Request message. And in this case, the UDR responds to NEF via Nudr DM Update Response message.
  • UDM may read from UDR, by means of Nudr DM Query, corresponding subscription information in order to validate required data updates and authorize these changes for this subscriber or Group for the corresponding AF.
  • the UDM resolves the GPSI to SUPI, and requests to create, update or delete the provisioned parameters as part of the subscriber data via Nudr DM Create/Update/Delete Request message, the message includes the provisioned data.
  • the UDM shall assign a unique Internal Group ID for the 5G VN group and include the newly assigned Internal Group ID in the Nudr DM Create Request message.
  • the UDM updates the UE and/or Group subscription data according to the AF/NEF request.
  • UDR stores the provisioned data as part of the UE and/or Group subscription data and responds with Nudr_DM_Create/Update/Delete Response message.
  • the UDR notifies to the subscribed PCF by sending Nudr_DM_Notify as defined in clause 4.16.12.2.
  • step 5 the reason to failure in Nudm ParameterProvision Update Response message and step 7 is not executed.
  • the UDM classifies the received parameters (e.g. Expected UE Behaviour parameters or the Network Configuration parameters or the 5G VN configuration parameters or Location Privacy Indication parameters), into AMF -Associated and SMF -Associated parameters.
  • the UDM may use the AF ID received from the NEF in step 2 to relate the received parameter with a particular subscribed DNN and/or S-NSSAI.
  • the UDM stores the SMF- Associated parameters under corresponding Session Management Subscription data type.
  • Each parameter or parameter set may be associated with a validity time.
  • the validity time is stored at the UDM/UDR and in each of the NFs, to which parameters are provisioned (e.g. in AMF or SMF).
  • each node Upon expiration of the validity time, each node deletes the parameters autonomously without explicit signalling.
  • UDM responds the request with Nudm ParameterProvision Create/Update/Delete Response. If the procedure failed, the cause value indicates the reason.
  • NEF responds the request with Nnef ParameterProvision Create/Update/Delete Response. If the procedure failed, the cause value indicates the reason.
  • UDM notifies the subscribed Network Function (e.g., AMF) of the updated UE and/or Group subscription data via Nudm_SDM_Notification Notify message.
  • AMF subscribed Network Function
  • the UDM performs Nudm SDM Notification (SUPI or Internal Group Identifier, AMF-Associated parameters, etc.) service operation.
  • the AMF identifies whether there are overlapping parameter set(s) and merges the parameter set(s) in the Expected UE Behaviour, if necessary.
  • the AMF uses the received AMF-Associated parameters to derive the appropriate UE configuration of the NAS parameters and to derive Core Network assisted RAN parameters.
  • the AMF may determine a Registration area based on parameters Stationary indication or Expected UE Moving Trajectory. b) If the NF is SMF, the UDM performs Nudm SDM Notification (SUPI or Internal Group Identifier, SMF- Associated parameter set, DNN/S-NSSAI, etc.) service operation.
  • Nudm SDM Notification SUPI or Internal Group Identifier, SMF- Associated parameter set, DNN/S-NSSAI, etc.
  • the SMF stores the received SMF -Associated parameters and associates them with a PDU Session based on the DNN and S-NSSAI included in the message from UDM.
  • the SMF identifies whether there are overlapping parameter set(s) in the Expected UE behaviour and merges the parameter set(s), if necessary.
  • the SMF may use the SMF- Associated parameters as follows: SMF configures the UPF accordingly.
  • the SMF can use the Scheduled Communication Type parameter or Suggested Number of Downlink Packets parameter to configure the UPF with how many downlink packets to buffer.
  • the SMF may use the parameter Communication duration time to determine to deactivate UP connection and to perform CN- initiated selective deactivation of UP connection of an existing PDU Session.
  • the SMF may derive SMF derived CN assisted RAN information for the PDU Session.
  • the SMF provides the SMF derived CN assisted RAN information to the AMF as described in PDU Session establishment procedure or PDU Session modification procedure.
  • NOTE 3 The NEF (in NOTE 1) or the UDM (in step 3) can also update the corresponding UDR data via Nudr DM Create/Delete as appropriate.
  • the Connection Management is used to establish and release the Control Plane signalling connection between the UE and the AMF.
  • the Registration Management is used to register or deregister a UE/user with the 5GS, and establish the user context in the 5GS.
  • the Mobility Management functions are used to keep track of the current location of a UE.
  • the procedures in clause 4.2 provides Connection, Registration and Mobility Management functionality.
  • a UE needs to register with the network to get authorized to receive services, to enable mobility tracking and to enable reachability.
  • the UE initiates the Registration procedure using one of the following Registration types:
  • Mobility Registration Update upon changing to a new Tracking Area (TA) outside the UE's Registration Area in both CM-CONNECTED and CM-IDLE state, or when the UE needs to update its capabilities or protocol parameters that are negotiated in Registration procedure with or without changing to a new TA, a change in the UE's Preferred Network Behaviour that would create an incompatibility with the Supported Network Behaviour provided by the serving AMF, or when the UE intends to retrieve LADN Information; or
  • Periodic Registration Update due to a predefined time period of inactivity
  • Emergency Registration due to a predefined time period of inactivity
  • 4G Tracking Area Update the indication that the UE is moving from EPS.
  • the PEI is obtained from the UE. If the PEI is needed (e.g. for EIR check), the AMF shall retrieve the PEI when it establishes the NAS security context with a Security Mode Command during initial registration. The AMF operator may check the PEI with an EIR. If the PEI was retrieved by the AMF (either from the UE or another AMF), AMF shall provide it to the UDM using Nudm UECM Regi strati on in order to ensure that the UDM always has the latest PEI available e.g. for reporting event Change of SUPI-PEI association. The AMF passes the PEI to the UDM, to the SMF and the PCF. The UDM may store this data in UDR by Nudr_SDM_Update.
  • NSI ID in the 5GC is optional and depends on the deployment choices of the operator.
  • the Home Network can provide Steering of Roaming information to the UE via the AMF (e.g. a list of preferred PLMN/access technology combinations or HPLMN indication that 'no change of the "Operator Controlled PLMN Selector with Access Technology" list stored in the UE is needed).
  • the Home Network can include an indication for the UE to send an acknowledgement of the reception of this information. Details regarding the handling of Steering of Roaming information including how this information is managed between the AMF and the UE are defined in TS 23.122 [22],
  • the AMF determines Access Type and RAT Type as defined in TS 23.501 [2] clause 5.3.2.3.
  • Figures 12A, 12B, and 12C depict an example process flow related to a registration procedure, which may be similar to Figure 4.2.2.2.2-1 of TS23.502.
  • the PDU Session establishment authentication/authorization is optionally triggered by the SMF during a PDU Session establishment and performed transparently via a UPF or directly with the DN-AAA server without involving the UPF if the DN-AAA server is located in the 5GC and reachable directly, as described in TS 23.501, clause 5.6.6.
  • the SMF in the information flow defined in this clause is the H-SMF.
  • Figure 13 illustrates an example protocol data unit (PDU) Session Establishment authentication/authorization by a 5G direct network authentication, authorization, and accounting (DN-AAA) server, in accordance with various embodiments.
  • PDU protocol data unit
  • DN-AAA 5G direct network authentication, authorization, and accounting
  • Steps 2, 3a, 3f and 4 may not be defined in the 3GPP specification. Step 3 can be repeated depending on the mechanism used.
  • Step 1 When the SMF directly communicates with the DN-AAA server without involving the UPF, Step 1 is skipped and Steps 2, 3a, 3f, 4 and 6 are executed without involving the UPF.
  • the SMF determines that it needs to contact the DN-AAA server.
  • the SMF identifies the DN-AAA server based on local configuration or using the DN-specific identity (TS 33.501 [15]) provided by the UE inside the SM PDU DN Request Container provided by the UE in the PDU Session Establishment request or inside the EAP message in the PDU Session Authentication Complete message (TS 24.501 [25]).
  • the SMF selects a UPF and triggers N4 session establishment.
  • the SMF initiates the authentication procedure with the DN-AAA via the UPF to authenticate the DN-specific identity provided by the UE as specified in TS 29.561 [63],
  • the SMF When available, the SMF provides the GPSI in the signalling exchanged with the DN- AAA.
  • the UPF transparently relays the message received from the SMF to the DN-AAA server.
  • the DN-AAA server sends an Authentication/ Authorization message towards the SMF.
  • the message is carried via the UPF.
  • the SMF invokes the Namf_Communication_NlN2MessageTransfer service operation on the AMF to transfer the DN Request Container information within N1 SM information sent towards the UE.
  • the H-SMF initiates a Nsmf PDUSession Update service operation to request the V-SMF to transfer DN Request Container to the UE and the V- SMF invokes the Namf_Communication_NlN2MessageTransfer service operation on the AMF to transfer the DN Request Container information within N 1 SM information sent towards the UE.
  • the H-SMF additionally includes the H-SMF SM Context ID.
  • the AMF sends the N1 NAS message to the UE
  • the AMF informs the SMF by invoking the Nsmf PDUSession UpdateSMContext service operation.
  • the SMF issues an Nsmf PDUSession UpdateSMContext response.
  • the V-SMF relays the N1 SM information to the H- SMF using the information of PDU Session received in step 3b via a Nsmf PDUSession Update service operation.
  • Step 3 may be repeated until the DN-AAA server confirms the successful authentication/authorization of the PDU Session.
  • the DN-AAA server confirms the successful authentication/authorization of the PDU Session.
  • the DN-AAA server may provide: an SM PDU DN Response Container to the SMF to indicate successful authenti cati on/ authorizati on;
  • DN Authorization Data as defined in TS 23.501 clause 5.6.6; a request to get notified with the IP address(es) allocated to the PDU Session and/or with N6 traffic routing information or MAC address(es) used by the UE for the PDU Session; and an IP address (or IPV6 Prefix) for the PDU Session.
  • the N6 traffic routing information is defined in TS 23.501 [2] clause 5.6.7.
  • a session is kept between the SMF and the DN-AAA. If the SMF receives a DN Authorization Data, the SMF uses the DN Authorization Profile Index to apply the policy and charging control (see TS 23.501 [2] clause 5.6.6).
  • the PDU Session establishment continues and completes.
  • the SMF receives the DN Authorization Profile Index in DN Authorization Data from the DN-AAA, it sends the DN Authorization Profile Index to retrieve the PDU Session related policy information (described in TS 23.503 [20] clause 6.4) and the PCC rule(s) (described in TS 23.503 [20] clause 6.3) from the PCF.
  • the SMF receives the DN authorized Session AMBR in DN Authorization Data from the DN-AAA, it sends the DN authorized Session AMBR within the Session AMBR to the PCF to retrieve the authorized Session AMBR (described in TS 23.503 [20] clause 6.4).
  • the SMF may instruct the UPF to handle VLAN information of the Ethernet frames related with the PDU Session received and sent on N6 or N19 or internal interface, as described in TS 23.501 [2] clause 5.6.10.2.
  • the SMF notifies the DN-AAA with the IP/MAC address(es) and/or with N6 traffic routing information allocated to the PDU Session together with the GPSI.
  • the DN-AAA server may revoke the authorization for a PDU Session or update DN authorization data for a PDU Session.
  • the SMF may release or update the PDU Session.
  • the DN-AAA server or SMF may initiate Secondary Re-authentication procedure for the PDU Session as specified in clause 11.1.3 in TS 33.501 [15], Step 3a to step 3f are performed to transfer the Secondary Re-authentication message between the UE and the DN-AAA server.
  • the Secondary Re-authentication procedure may start from step 3a (DN-AAA initiated Secondary Re-authentication procedure) or step 3b (SMF initiated Secondary Re-authentication procedure).
  • the message in step 3a shall include GPSI, if available, and the IP/MAC address(es) of the PDU session, for SMF to identify the corresponding UE and PDU session.
  • DN-AAA may initiate DN-AAA Re-authorization without performing re-authentication based on local policy.
  • DN-AAA Re-authorization procedure may start from step 4.
  • the SMF reports the received value(s) to the PCF (as described in TS 23.501 [2]) by triggering the Policy Control Request Trigger as described in TS 23.503 [20],
  • a PDU Session establishment may correspond to: a UE initiated PDU Session Establishment procedure. a UE initiated PDU Session handover between 3 GPP and non-3GPP. a UE initiated PDU Session handover from EPS to 5GS. a Network triggered PDU Session Establishment procedure.
  • the network sends the device trigger message to application(s) on the UE side.
  • the payload included in Device Trigger Request message contains information on which application on the UE side is expected to trigger the PDU Session establishment request. Based on that information, the application(s) on the UE side trigger the PDU Session Establishment procedure. For more detail refer to clause 4.13.2.
  • the functional entities in the following procedures are located in the PLMN of the access used to exchange NAS with the UE for the PDU Session.
  • a PDU Session may be associated either (a) with a single access type at a given time, e.g. either 3 GPP access or non-3GPP access, or (b) simultaneously with multiple access types, e.g. one 3GPP access and one non-3GPP access.
  • a PDU Session associated with multiple access types is referred to as Multi Access-PDU (MA PDU) Session and it may be requested by ATSSS-capable UEs.
  • MA PDU Multi Access-PDU
  • Clause 4.3.2.2.1 specifies PDU Session establishment in the non-roaming and roaming with local breakout cases. The procedure is used to:
  • the AMF determines if a PDU Session is to be established in LBO or Home Routing.
  • LBO the procedure is as in the case of non-roaming with the difference that the AMF, the SMF, the UPF and the PCF are located in the visited network.
  • PDU Sessions for Emergency services are never established in Home Routed mode. If Control Plane CIoT 5GS Optimisation is enabled for the PDU session with LBO, the NEF is not used as the anchor of this PDU Session.
  • Figures 14A-B illustrate an example UE -requested PDU Session Establishment for nonroaming and roaming with local breakout, in accordance with various embodiments.
  • Figures 14A-B may be similar to, for example, Figure 4.3.2.2.1-1.
  • the procedure assumes that the UE has already registered on the AMF thus unless the UE is Emergency Registered the AMF has already retrieved the user subscription data from the UDM. 1. From UE to AMF : NAS Message (S-NSSAI(s), UE Requested DNN, PDU Session
  • the UE In order to establish a new PDU Session, the UE generates a new PDU Session ID.
  • the UE initiates the UE Requested PDU Session Establishment procedure by the transmission of a NAS message containing a PDU Session Establishment Request within the N1 SM container.
  • the PDU Session Establishment Request includes a PDU session ID, Requested PDU Session Type, a Requested SSC mode, 5GSM Capability, PCO, SM PDU DN Request Container, [Number Of Packet Filters], [Header Compression Configuration], UE Integrity Protection Maximum Data Rate, and [Always-on PDU Session Requested],
  • the Request Type indicates "Initial request” if the PDU Session Establishment is a request to establish a new PDU Session and indicates "Existing PDU Session” if the request refers to an existing PDU Session switching between 3GPP access and non-3GPP access or to a PDU Session handover from an existing PDN connection in EPC. If the request refers to an existing PDN connection in EPC, the S-NSSAI is set as described in TS 23.501 [2] clause 5.15.7.2
  • a UE When Emergency service is required and an Emergency PDU Session is not already established, a UE shall initiate the UE Requested PDU Session Establishment procedure with a Request Type indicating "Emergency Request".
  • the Request Type indicates "Emergency Request” if the PDU Session Establishment is a request to establish a PDU Session for Emergency services.
  • the Request Type indicates "Existing Emergency PDU Session” if the request refers to an existing PDU Session for Emergency services switching between 3GPP access and non-3GPP access or to a PDU Session handover from an existing PDN connection for Emergency services in EPC.
  • the 5GSM Core Network Capability is provided by the UE and handled by SMF as defined in TS 23.501 [2] clause 5.4.4b.
  • the Number Of Packet Filters indicates the number of supported packet filters for signalled QoS rules for the PDU Session that is being established.
  • the number of packet filters indicated by the UE is valid for the lifetime of the PDU Session. For presence condition, see TS 24.501 [25],
  • the UE Integrity Protection Maximum Data Rate indicates the maximum data rate up to which the UE can support UP integrity protection.
  • the UE shall provide the UE Integrity Protection Data Rate capability independently of the Access Type over which the UE sends the PDU Session Establishment Request.
  • the UE shall include the Header Compression Configuration, unless "Unstructured" PDU Session Type is indicated.
  • the Header Compression Configuration includes the information necessary for the header compression channel setup.
  • the Header Compression Configuration may include additional header compression context parameters.
  • the NAS message sent by the UE is encapsulated by the AN in a N2 message towards the AMF that should include User location information and Access Type Information.
  • the PDU Session Establishment Request message may contain SM PDU DN Request Container containing information for the PDU Session authorization by the external DN.
  • the UE includes the S-NSSAI from the Allowed NSSAI of the current access type. If the Mapping of Allowed NSSAI was provided to the UE, the UE shall provide both the S-NSSAI of the VPLMN from the Allowed NSSAI and the corresponding S-NSSAI of the HPLMN from the Mapping Of Allowed NSSAI.
  • the UE shall also include the Old PDU Session ID which indicates the PDU Session ID of the on-going PDU Session to be released, in NAS message.
  • the Old PDU Session ID is included only in this case.
  • the AMF receives from the AN the NAS SM message (built in step 1) together with User Location Information (e.g. Cell Id in the case of the NG-RAN).
  • User Location Information e.g. Cell Id in the case of the NG-RAN.
  • the UE shall not trigger a PDU Session establishment for a PDU Session corresponding to a LADN when the UE is outside the area of availability of the LADN.
  • the UE shall include an indicator that it requests a P-CSCF IP address(es) within the SM container.
  • the PS Data Off status is included in the PCO in the PDU Session Establishment Request message.
  • the UE capability to support Reliable Data Service is included in the PCO in the PDU Session Establishment Request message.
  • the UE shall include the MAC address of the DS-TT Ethernet port used for this PDU session. If the UE is aware of the UE-DS-TT Residence Time, then the UE shall additionally include the UE-DS-TT Residence Time.
  • the UE If the UE requests to establish always-on PDU session, the UE includes an Always-on PDU Session Requested indication in the PDU Session Establishment Request message.
  • Port Management Information Container is received from DS-TT and includes port management capabilities, e.g. information indicating which standardized and deployment-specific port management information is supported by DS-TT as defined in TS 23.501 [2] clause 5.28.3. 2.
  • the AMF determines that the message corresponds to a request for a new PDU Session based on that Request Type indicates "initial request" and that the PDU Session ID is not used for any existing PDU Session of the UE. If the NAS message does not contain an S-NSSAI, the AMF determines an S-NSSAI of the Serving PLMN for the requested PDU Session from the current Allowed NSSAI for the UE.
  • this S- NSSAI shall be used. If there is more than one S-NSSAI in the Allowed NSSAI, the S-NSSAI selected is either according to the UE subscription, if the subscription contains only one default S-NSSAI and the corresponding mapped HPLMN S-NSSAI of the Serving PLMN is included in the Allowed NSSAI, or based on operator policy (e.g. also ensures any UE Requested DNN is allowed for the selected S-NSSAI)).
  • the AMF determines the DNN for the requested PDU Session by selecting the default DNN for this S-NSSAI if the default DNN is present in the UE's Subscription Information (or for the corresponding S-NSSAI of the HPLMN, in the case of LBO); otherwise the serving AMF selects a locally configured DNN for this S-NSSAI of the Serving PLMN. If the AMF cannot select an SMF (e.g.
  • the AMF shall, based on operator policies received from PCF, either reject the NAS Message containing PDU Session Establishment Request from the UE with an appropriate cause or request PCF to replace the UE requested DNN by a selected DNN. If the DNN requested by the UE is present in the UE subscription information but indicated for replacement in the operator policies received from PCF, the AMF shall request the PCF to perform a DNN replacement to a selected DNN.
  • AMF requests DNN replacement as as specified in clause 4.16.2.1.1. If the DNN requested by the UE is present in the UE subscription information but not supported by the network and not indicated for replacement in the operator policies received from PCF, the AMF shall reject the NAS Message containing PDU Session Establishment Request from the UE with an appropriate cause value.
  • the AMF selects an SMF as described in clause 6.3.2 of TS 23.501 [2] and clause 4.3.2.2.3. If the Request Type indicates "Initial request" or the request is due to handover from EPS or from non-3GPP access serving by a different AMF, the AMF stores an association of the S-NSSAI(s), the DNN, the PDU Session ID, the SMF ID as well as the Access Type of the PDU Session.
  • the AMF determines the use of the Control Plane CIoT 5GS Optimisation or User Plane CIoT 5GS Optimisation based on UEs indications in the 5G Preferred Network Behaviour, the serving operator policies and the network support of CIoT 5GS optimisations.
  • the AMF selects an SMF that supports Control Plane CIoT 5GS optimisation or User Plane CIoT 5GS Optimisation as described in clause 6.3.2 of TS 23.501 [2],
  • the AMF selects an SMF as described in clause 4.3.5.2 and stores an association of the new PDU Session ID, the S-NSSAI(s), the selected SMF ID as well as Access Type of the PDU Session.
  • the AMF selects the SMF based on SMF -ID received from UDM.
  • SMF -ID received from UDM.
  • the case where the Request Type indicates "Existing PDU Session”, and either the AMF does not recognize the PDU Session ID or the subscription context that the AMF received from UDM during the Registration or Subscription Profile Update Notification procedure does not contain an SMF ID corresponding to the PDU Session ID constitutes an error case.
  • the AMF updates the Access Type stored for the PDU Session.
  • the PDU Session Establishment procedure can be performed in the following cases: the SMF ID corresponding to the PDU Session ID and the AMF belong to the same PLMN; the SMF ID corresponding to the PDU Session ID belongs to the HPLMN;
  • the AMF shall reject the PDU Session Establishment Request with an appropriate reject cause.
  • the SMF ID includes the PLMN ID that the SMF belongs to.
  • the AMF shall reject a request coming from an Emergency Registered UE and the Request Type indicates neither "Emergency Request” nor "Existing Emergency PDU Session".
  • the Request Type indicates "Emergency Request”
  • the AMF is not expecting any S-NSSAI and DNN value provided by the UE and uses locally configured values instead.
  • the AMF stores the Access Type of the PDU Session.
  • the AMF selects the SMF as described in TS 23.501 [2], clause 5.16.4.
  • Nsmf PDUSession CreateSMContext Request (SUPI, selected DNN, UE requested DNN, S-NSSAI(s), PDU Session ID, AMF ID, Request Type, PCF ID, Priority Access, [Small Data Rate Control Status], N1 SM container (PDU Session Establishment Request), User location information, Access Type, RAT Type, PEI, GPSI, UE presence in LADN service area, Subscription For PDU Session Status Notification, DNN Selection Mode, Trace Requirements, Control Plane CIoT 5GS Optimisation indication, or Control Plane Only indicator) or Nsmf PDUSession UpdateSMContext Request (SUPI, DNN, S-NSSAI(s), SM Context ID, AMF ID, Request Type, N1 SM container (PDU Session Establishment Request), User location information, Access Type, RAT type, PEI, Serving Network (PLMN ID, or PLMN ID and NID
  • the AMF invokes the Nsmf PDUSession CreateSMContext Request, but if the AMF already has an association with an SMF for the PDU Session ID provided by the UE (e.g. when Request Type indicates "existing PDU Session"), the AMF invokes the Nsmf PDUSession UpdateSMContext Request.
  • the AMF sends the S-NSSAI of the Serving PLMN from the Allowed NSSAI to the SMF.
  • the AMF also sends the corresponding S-NSSAI of the HPLMN from the Mapping Of Allowed NSSAI to the SMF.
  • the AMF ID is the UE's GUAMI which uniquely identifies the AMF serving the UE.
  • the AMF forwards the PDU Session ID together with the N1 SM container containing the PDU Session Establishment Request received from the UE.
  • the GPSI shall be included if available at AMF.
  • the AMF determines Access Type and RAT Type, see clause 4.2.2.2.L
  • the AMF provides the PEI instead of the SUPI when the UE in limited service state has registered for Emergency services (e.g. Emergency Registered) without providing a SUPI.
  • the PEI is defined in TS 23.501 [2] clause 5.9.3. If the UE in limited service state has registered for Emergency services (e.g. Emergency Registered) with a SUPI but has not been authenticated the AMF indicates that the SUPI has not been authenticated. The SMF determines that the UE has not been authenticated when it does not receive a SUPI for the UE or when the AMF indicates that the SUPI has not been authenticated.
  • the AMF determines that the selected DNN corresponds to an LADN then the AMF provides the "UE presence in LADN service area" that indicates if the UE is IN or OUT of the LADN service area.
  • the AMF also includes Old PDU Session ID in the Nsmf PDUSession CreateSMContext Request.
  • DNN Selection Mode is determined by the AMF. It indicates whether an explicitly subscribed DNN has been provided by the UE in its PDU Session Establishment Request.
  • the SMF may use DNN Selection Mode when deciding whether to accept or reject the UE request.
  • the AMF includes a Message Priority header to indicate priority information.
  • the SMF uses the Message Priority header to determine if the UE request is subject to exemption from NAS level congestion control.
  • Other NFs relay the priority information by including the Message Priority header in service-based interfaces, as specified in TS 29.500 [17],
  • the SMF in the VPLMN
  • the SMF responds to the AMF that it is not the right SMF to handle the N1 SM message by invoking Nsmf PDUSession CreateSMContext Response service operation.
  • the SMF includes a proper Ni l cause code triggering the AMF to proceed with home routed case. The procedure starts again at step 2 of clause 4.3.2.2.2.
  • the AMF may include a PCF ID in the Nsmf PDUSession CreateSMContext Request. This PCF ID identifies the H-PCF in the non-roaming case and the V-PCF in the local breakout roaming case.
  • the AMF includes Trace Requirements if Trace Requirements have been received in subscription data.
  • the AMF decides to use the Control Plane CIoT 5GS Optimisation or User Plane CIoT 5GS Optimisation as specified in step 2 or to only use Control Plane CIoT 5GS Optimisation for the PDU session as described in clause 5.31.4 of TS 23.501 [2], the AMF sends the Control Plane CIoT 5GS Optimisation indication or Control Plane Only indicator to the SMF.
  • the AMF may either reject the PDU Session Establishment Request or continue with the PDU Session establishment and include the Control Plane CIoT 5GS Optimisation indication or Control Plane Only indicator to the SMF.
  • the AMF includes the latest Small Data Rate Control Status if it has stored it for the PDU Session.
  • the SMF stores the RAT type in SM Context.
  • the AMF shall include the extended NAS-SM timer indication. Based on the extended NAS-SM timer indication, the SMF shall use the extended NAS-SM timer setting for the UE as specified in TS 24.501 [25],
  • Session Management Subscription data for corresponding SUPI, DNN and S- NSSAI of the HPLMN is not available, then SMF retrieves the Session Management Subscription data using Nudm_SDM_Get (SUPI, Session Management Subscription data, selected DNN, S- NSSAI of the HPLMN, Serving PLMN ID, [NID]) and subscribes to be notified when this subscription data is modified using Nudm SDM Subscribe (SUPI, Session Management Subscription data, selected DNN, S-NSSAI of the HPLMN, Serving PLMN ID, [NID]).
  • Nudm_SDM_Get SUPI, Session Management Subscription data, selected DNN, S-NSSAI of the HPLMN, Serving PLMN ID, [NID]
  • UDM may get this information from UDR by Nudr DM Query (SUPI, Subscription Data, Session Management Subscription data, selected DNN, S-NSSAI of the HPLMN, Serving PLMN ID, [NID]) and may subscribe to notifications from UDR for the same data by Nudr DM sub scribe.
  • Nudr DM Query SUPI, Subscription Data, Session Management Subscription data, selected DNN, S-NSSAI of the HPLMN, Serving PLMN ID, [NID]
  • the SMF may use DNN Selection Mode when deciding whether to retrieve the Session Management Subscription data e.g. if the (selected DNN, S-NSSAI of the HPLMN) is not explicitly subscribed, the SMF may use local configuration instead of Session Management Subscription data.
  • the SMF determines that the request is due to switching between 3GPP access and non-3GPP access or due to handover from EPS.
  • the SMF identifies the existing PDU Session based on the PDU Session ID. In such a case, the SMF does not create a new SM context but instead updates the existing SM context and provides the representation of the updated SM context to the AMF in the response.
  • the SMF identifies the existing PDU Session to be released based on the Old PDU Session ID.
  • Subscription data includes the Allowed PDU Session Type(s), Allowed SSC mode(s), default 5QI and ARP, subscribed Session-AMBR, SMF -Associated external parameters.
  • Static IP address/prefix may be included in the subscription data if the UE has subscribed to it.
  • the SMF checks the validity of the UE request: it checks
  • the selected DNN corresponds to an LADN
  • whether the UE is located within the LADN service area based on the "UE presence in LADN service area" indication from the AMF. If the AMF does not provide the "UE presence in LADN service area" indication and the SMF determines that the selected DNN corresponds to a LADN, then the SMF considers that the UE is OUT of the LADN service area.
  • the SMF determines whether the PDU Session requires redundancy and the SMF determines the RSN as described in TS 23.501 [2] clause 5.33.2.1. If the SMF determines that redundant handling is not allowed or not possible for the given PDU Session, the SMF shall either reject the establishment of the PDU Session or accept the establishment of a PDU session without redundancy handling based on local policy.
  • the SMF decides to not accept to establish the PDU Session.
  • Nsmf PDUSession CreateSMContext Response (Cause, SM Context ID or N1 SM container (PDU Session Reject (Cause))
  • Nsmf PDUSession UpdateSMContext Response depending on the request received in step 3.
  • the SMF If the SMF received Nsmf PDUSession CreateSMContext Request in step 3 and the SMF is able to process the PDU Session establishment request, the SMF creates an SM context and responds to the AMF by providing an SM Context ID.
  • the SMF may, based on local configuration, decide whether to accept or reject the PDU Session request based on the UE Integrity Protection Maximum Data Rate.
  • the SMF can e.g. be configured to reject a PDU Session if the UE Integrity
  • the SMF When the SMF decides to not accept to establish a PDU Session, the SMF rejects the UE request via NAS SM signalling including a relevant SM rejection cause by responding to the AMF with Nsmf PDUSession CreateSMContext Response.
  • the SMF also indicates to the AMF that the PDU Session ID is to be considered as released, the SMF proceeds to step 20 and the PDU Session Establishment procedure is stopped.
  • the SMF does not perform secondary authentication/authorization.
  • the SMF shall not perform secondary authentication ⁇ authorization. If the SMF needs to perform secondary authentication/authorization during the establishment of the PDU Session by a DN-AAA server as described in TS 23.501 [2] clause 5.6.6, the SMF triggers the PDU Session establishment authentication/authorization as described in clause 4.3.2.3.
  • the SMF performs PCF selection as described in TS 23.501 [2], clause 6.3.7.1. If the Request Type indicates "Existing PDU Session” or "Existing Emergency PDU Session", the SMF shall use the PCF already selected for the PDU Session.
  • the SMF may apply local policy.
  • the SMF may perform an SM Policy Association Establishment procedure as defined in clause 4.16.4 to establish an SM Policy Association with the PCF and get the default PCC Rules for the PDU Session.
  • the GPSI shall be included if available at SMF.
  • the SMF may provide information on the Policy Control Request Trigger condition(s) that have been met by an SMF initiated SM Policy Association Modification procedure as defined in clause 4.16.5.1.
  • the PCF may provide policy information defined in clause 5.2.5.4 (and in TS 23.503 [20]) to SMF.
  • the PCF based on the Emergency DNN, sets the ARP of the PCC rules to a value that is reserved for Emergency services as described in TS 23.503 [20],
  • step 7 The purpose of step 7 is to receive PCC rules before selecting UPF. If PCC rules are not needed as input for UPF selection, step 7 can be performed after step 8.
  • the SMF selects an SSC mode for the PDU Session as described in TS 23.501 [2] clause 5.6.9.3.
  • the SMF also selects one or more UPFs as needed as described in TS 23.501 [2] clause 6.3.3.
  • the SMF allocates an IP address/prefix for the PDU Session (unless configured otherwise) as described in TS 23.501 [2] clause 5.8.2.
  • the SMF also allocates an interface identifier to the UE for the UE to build its link-local address.
  • the SMF may allocate an IPv6 prefix for the PDU Session and N6 point-to-point tunnelling (based on UDP/IPv6) as described in TS 23.501 [2] clause 5.6.10.3.
  • IPv6 prefix for the PDU Session and N6 point-to-point tunnelling
  • MAC For Ethernet PDU Session Type, neither a MAC nor an IP address is allocated by the SMF to the UE for this PDU Session.
  • the SMF checks whether UE's subscription include a "NEF Identity forNIDD" for the DNN/S-NSSAI combination.
  • the SMF will select the NEF identified for the S-NSSAI and selected DNN in the "NEF Identity for NIDD" as the anchor of this PDU Session. Otherwise, the SMF will select a UPF as the anchor of this PDU Session.
  • the SMF will perform UPF selection to select a UPF as the anchor of this PDU Session.
  • the SMF maintains the same IP address/prefix that has already been allocated to the UE in the source network.
  • step 3 If the Request Type in step 3 indicates "Existing PDU Session" referring to an existing PDU Session moved between 3 GPP access and non-3GPP access the SMF maintains the SSC mode of the PDU Session, the current PDU Session Anchor and IP address.
  • the SMF may decide to trigger e.g. new intermediate UPF insertion or allocation of a new UPF as described in step 5 in clause 4.2.3.2.
  • the SMF selects the UPF as described in TS 23.501 [2] clause 5.16.4 and selects SSC mode 1.
  • SMF may select a UPF (e.g. based on requested DNN/S-NSSAI) that supports NW-TT functionality.
  • a UPF e.g. based on requested DNN/S-NSSAI
  • SMF may perform an SMF initiated SM Policy Association Modification procedure as defined in clause 4.16.5.1 to provide information on the Policy Control Request Trigger condition(s) that have been met. If Request Type is "initial request” and dynamic PCC is deployed and PDU Session Type is IPv4 or IPv6 or IPv4v6, SMF notifies the PCF (if the Policy Control Request Trigger condition is met) with the allocated UE IP address/prefix(es).
  • the SMF shall further report the PS Data Off status to PCF if the PS Data Off Policy Control Request Trigger is provisioned, the additional behaviour of SMF and PCF for 3GPP PS Data Off is defined in TS 23.503 [20],
  • PCF may provide updated policies to the SMF.
  • the PCF may provide policy information defined in clause 5.2.5.4 (and in TS 23.503 [20]) to SMF.
  • Request Type indicates "initial request"
  • the SMF initiates an N4 Session Establishment procedure with the selected UPF(s), otherwise it initiates an N4 Session Modification procedure with the selected UPF(s):
  • the SMF sends anN4 Session Establishment/Modification Request to the UPF and provides Packet detection, enforcement and reporting rules to be installed on the UPF for this PDU Session. If the SMF is configured to request IP address allocation from UPF as described in TS 23.501 [2] clause 5.8.2 then the SMF indicates to the UPF to perform the IP address/prefix allocation, and includes the information required for the UPF to perform the allocation. If the selective User Plane deactivation is required for this PDU Session, the SMF determines the Inactivity Timer and provides it to the UPF. The SMF provides Trace Requirements to the UPF if it has received Trace Requirements.
  • the RDS Configuration information is provided to the UPF in this step.
  • the SMF provides Small Data Rate Control parameters to the UPF for the PDU Session, if required.
  • the SMF provides the Small Data Rate Control Status to the UPF, if received from the AMF. If the Serving PLMN intends to enforce Serving PLMN Rate Control (see clause 5.31.14.2 of TS 23.501 [2]) for this PDU session then the SMF shall provide Serving PLMN Rate Control parameters to UPF for limiting the rate of downlink control plane data packets.
  • SMF e.g. for a certain requested DNN/S-NSSAI
  • SMF may include an indication to request UPF to provide port numbers.
  • the SMF If SMF decides to insert two I-UPF s between the PSA UPF and the NG-RAN for redundant transmission as described in clause 5.33.1.2 ofTS 23.501 [2], the SMF requests the corresponding CN Tunnel Info and provides them to the I-UPFs and PSA UPF respectively. The SMF also indicates the PSA UPF to eliminate the duplicated packet for the QoS Flow in uplink direction. The SMF indicates the PSA UPF that one CN Tunnel Info is used as the redundancy tunnel of the PDU session described in clause 5.33.2.2 of TS 23.501 [2],
  • Control Plane CIoT 5GS Optimiation is enabled for this PDU session and the SMF selects the NEF as the anchor of this PDU Session in step 8, the SMF performs SMF-NEF Connection Establishment Procedure as described in clause 4.25.2.
  • the UPF acknowledges by sending an N4 Session Establishment/Modification Response.
  • step 10a If the SMF indicates in step 10a that IP address/prefix allocation is to be performed by the UPF then this response contains the requested IP address/prefix.
  • the requested CN Tunnel Info is provided to SMF in this step. If SMF indicated the UPF to perform packet duplication and elimination for the QoS Flow in step 10a, two CN Tunnel Info are allocated by the UPF and provided to the SMF. If SMF decides to insert two I-UPFs between the PSA UPF and the NG- RAN for redundant transmission as described in clause 5.33.1.2 of TS 23.501 [2], CN Tunnel Info of two I-UPFs and the UPF (PSA) are allocated by the UPFs and provided to the SMF. The UPF indicates the SMF that one CN Tunnel Info is used as the redundancy tunnel of the PDU session as described in clause 5.33.2.2 of TS 23.501 [2],
  • UPF includes the DS-TT port and Bridge ID in the response according to TS 23.501 [2],
  • the SMF initiate N4 Session Establishment/Modification procedure with each UPF of the PDU Session in this step.
  • Trigger (as specified in clause 6.1.3.5 of TS 23.503 [20]) then the SMF notifies the PCF about the IP address/prefix allocated by the UPF. This is not shown in figure 4.3.2.2.1-1.
  • SMF to AMF Namf_Communication_NlN2MessageTransfer (PDU Session ID, N2 SM information (PDU Session ID, QFI(s), QoS Profile(s), CN Tunnel Info, S-NSSAI from the Allowed NSSAI, Session-AMBR, PDU Session Type, User Plane Security Enforcement information, UE Integrity Protection Maximum Data Rate, RSN), N1 SM container (PDU Session Establishment Accept ([QoS Rule(s) and QoS Flow level QoS parameters if needed for the QoS Flow(s) associated with the QoS rule(s)], selected SSC mode, S-NSSAI(s), UE Requested DNN, allocated IPv4 address, interface identifier, Session-AMBR, selected PDU Session Type, [Reflective QoS Timer] (if available), [P-CSCF address(es)], [Control Plane Only indicator], [Header Compression Configuration], [Al
  • the SMF may provide the SMF derived CN assisted RAN parameters tuning to the AMF by invoking Nsmf_PDUSession_SMContextStatusNotify (SMF derived CN assisted RAN parameters tuning) service.
  • the AMF stores the SMF derived CN assisted RAN parameters tuning in the associated PDU Session context for this UE.
  • the N2 SM information carries information that the AMF shall forward to the (R)AN which includes:
  • the CN Tunnel Info corresponds to the Core Network address(es) of the N3 tunnel corresponding to the PDU Session. If two CN Tunnel Info are included for the PDU session for redundant transmission, the SMF also indicates the NG-RAN that one of the CN Tunnel Info used as the redundancy tunnel of the PDU session as described in clause 5.33.2.2 of TS 23.501 [2], One or multiple QoS profiles and the corresponding QFIs can be provided to the (R)AN. This is further described in TS 23.501 [2] clause 5.7. The SMF may indicate for each QoS Flow whether redundant transmission shall be performed by a corresponding redundant transmission indicator.
  • the PDU Session ID may be used by AN signalling with the UE to indicate to the UE the association between (R)AN resources and a PDU Session for the UE.
  • a PDU Session is associated to an S-NSSAI of the HPLMN and, if applicable, to a S-NSSAI of the VPLMN, and a DNN.
  • the S-NSSAI provided to the (R)AN is the S-NSSAI with the value for the Serving PLMN (e.g. the HPLMN S-NSSAI or, in LBO roaming case, the VPLMN S-NSSAI).
  • the SMF also includes the UE Integrity Protection Maximum Data Rate as received in the PDU Session Establishment Request.
  • the N1 SM container contains the PDU Session Establishment Accept that the AMF shall provide to the UE. If the UE requested P-CSCF discovery then the message shall also include the P-CSCF IP address(es) as determined by the SMF and as described in TS 23.501 [2] clause 5.16.3.4.
  • the PDU Session Establishment Accept includes S-NSSAI from the Allowed NS SAI. For LBO roaming scenario, the PDU Session Establishment Accept includes the S-NSSAI from the Allowed NS SAI for the VPLMN and also it includes the corresponding S-NSSAI of the HPLMN from the Mapping Of Allowed NSSAI that SMF received in step 3.
  • the SMF shall indicate whether the request is accepted by including an Always-on PDU Session Granted indication in the PDU Session Establishment Accept message. If the PDU Session being established was not requested to be an always-on PDU Session but the SMF determines that the PDU Session needs to be established as an always-on PDU Session, the SMF shall include an Always-on PDU Session Granted indication in the PDU Session Establishment Accept message indicating that the PDU session is an always-on PDU Session.
  • Control Plane CIoT 5GS Optimisation is enabled for this PDU session, the N2 SM information is not included in this step. If Control Plane CIoT 5GS optimisation is enabled for this PDU session, and the UE has sent the Header Compression Configuration in the PDU Session Establishment Request, and the SMF supports the header compression parameters, the SMF shall include the Header Compression Configuration in the PDU Session Establishment Accept message. If the UE has included Header Compression context parameters in Header Compression Configuration in the PDU Session Establishment Request, the SMF shall establish the header compression context and may acknowledge the Header Compression context parameters.
  • the UE and the SMF need to establish the header compression context based on the Header Compression Configuration. If the SMF has received the Control Plane Only Indicator in step 3, the SMF shall include the Control Plane Only Indicator in the PDU Session Establishment Accept message. The SMF shall indicate the use of Control Plane only on its CDR.
  • the SMF shall also include Small Data Rate Control parameters and the Small Data Rate Control Status (if received from the AMF) in the PDU Session Establishment Accept message as described in clause 5.31.14.3 of TS 23.501 [2], If the Serving PLMN intends to enforce Serving PLMN Rate Control (see clause 5.31.14.2 of TS 23.501 [2]) for this PDU session then the SMF shall include the Serving PLMN Rate Control parameters in the PDU Session Establishment Accept message. The UE shall store and use Serving PLMN Rate Control parameters as the maximum allowed limit of uplink control plane user data.
  • the SMF shall inform the UE that RDS is enabled in the PCO in the PDU Session Establishment Accept (see clause 5.31.6 of TS 23.501 [2]).
  • the SMF shall inform the UE of the NIDD parameters in the PCO in the PDU Session Establishment Accept (see clause 5.31.5 of TS 23.501 [2]).
  • QoS Flow level QoS parameters if needed for the QoS Flow(s) associated with those QoS rule(s) and QoS Profiles may be included in the PDU Session Establishment Accept within the N1 SM and in the N2 SM information.
  • the Namf_Communication_NlN2MessageTransfer contains the PDU Session ID allowing the AMF to know which access towards the UE to use.
  • the Namf_Communication_NlN2MessageTransfer request shall include the N1 SM container with a PDU Session Establishment Reject message (see clause 8.3.3 of TS 24.501 [25]) and shall not include any N2 SM container.
  • the (R)AN sends the NAS message containing the PDU Session Establishment Reject to the UE. In this case, steps 12-17 are skipped. 12.
  • AMF to (R)AN N2 PDU Session Request (N2 SM information, NAS message (PDU Session ID, N1 SM container (PDU Session Establishment Accept)), [CN assisted RAN parameters tuning]). If the N2 SM information is not included in the step 11, an N2 Downlink NAS Transport message is used instead.
  • the AMF sends the NAS message containing PDU Session ID and PDU Session Establishment Accept targeted to the UE and the N2 SM information received from the SMF within the N2 PDU Session Request to the (R)AN.
  • the AMF may derive updated CN assisted RAN parameters tuning and provide them the (R)AN.
  • the (R)AN may issue AN specific signalling exchange with the UE that is related with the information received from SMF. For example, in the case of a NG-RAN, an RRC Connection Reconfiguration may take place with the UE establishing the necessary NG- RAN resources related to the QoS Rules for the PDU Session request received in step 12.
  • (R)AN also allocates (R)AN Tunnel Info for the PDU Session.
  • the Master RAN node may assign some (zero or more) QFIs to be setup to a Master RAN node and others to the Secondary RAN node.
  • the AN Tunnel Info includes a tunnel endpoint for each involved (R)AN node, and the QFIs assigned to each tunnel endpoint.
  • a QFI can be assigned to either the Master RAN node or the Secondary RAN node and not to both.
  • (R)AN receives two CN Tunnel Info for a PDU session in step 12 for redundant transmission
  • (R)AN also allocates two AN Tunnel Info correspondingly, and indicate to SMF one of the AN Tunnel Info is used as the redundancy tunnel of the PDU session as described in clause 5.33.2.2 of TS 23.501 [2],
  • (R)AN forwards the NAS message (PDU Session ID, N 1 SM container (PDU Session Establishment Accept)) provided in step 12 to the UE.
  • (R)AN shall only provide the NAS message to the UE if the AN specific signalling exchange with the UE includes the (R)AN resource additions associated to the received N2 command.
  • MICO mode is active and the NAS message Request Type in step 1 indicated "Emergency Request", then the UE and the AMF shall locally deactivate MICO mode.
  • step 11 If the N2 SM information is not included in the step 11, then the following steps 14 to 16b and step 17 are omitted.
  • N2 PDU Session Response PDU Session ID, Cause, N2 SM information (PDU Session ID, AN Tunnel Info, List of accepted/rejected QFI(s), User Plane Enforcement Policy Notification)).
  • the AN Tunnel Info corresponds to the Access Network address of the N3 tunnel corresponding to the PDU Session.
  • the SMF is responsible of updating the QoS rules and QoS Flow level QoS parameters if needed for the QoS Flow associated with the QoS rule(s) in the UE accordingly.
  • the NG-RAN rejects the establishment of UP resources for the PDU Session when it cannot fulfil User Plane Security Enforcement information with a value of Required.
  • the NG-RAN notifies the SMF when it cannot fulfil a User Plane Security Enforcement with a value of Preferred.
  • the NG-RAN takes the decision on whether to reject the establishment of RAN resources for the PDU Session based on local policies as described in TS 23.501 [2],
  • AMF to SMF Nsmf PDUSession UpdateSMContext Request (SM Context ID, N2 SM information, Request Type).
  • the AMF forwards the N2 SM information received from (R)AN to the SMF.
  • the SMF shall release the rejected QFI(s) associated QoS profiles.
  • the SMF shall reject the PDU session establishment by including a N1 SM container with a PDU Session Establishment Reject message (see clause 8.3.3 of TS 24.501 [25]) in the Nsmf PDUSession UpdateSMContext Response in step 17. Step 16 is skipped in this case and instead the SMF releases the N4 Session with UPF.
  • the SMF shall reject the PDU session establishment by including a N1 SM container with a PDU Session Establishment Rej ect message (see clause 8.3.3 of TS 24.501 [25]) in the Nsmf_PDUSession_UpdateSMContext Response in step 17. Step 16 is skipped in this case.
  • the SMF initiates an N4 Session Modification procedure with the UPF.
  • the SMF provides AN Tunnel Info to the UPF as well as the corresponding forwarding rules.
  • the SMF decides to perform redundant transmission for one or more QoS Flows of the PDU, the SMF also indicates the UPF to perform packet duplication for the QoS Flow(s) in downlink direction by forwarding rules.
  • the SMF provides AN Tunnel Info to two I-UPFs and also indicates the UPF (PSA) to perform packet duplication for the QoS Flow(s) in downlink direction by forwarding rules.
  • the SMF also provides the UL Tunnel Info of the UPF (PSA) to the two I-UPFs and the DL Tunnel Info of the two I-UPFs to the UPF (PSA).
  • the UPF provides an N4 Session Modification Response to the SMF.
  • the UPF in step 16 refers to the UPF terminating N3.
  • the UPF delivers any down-link packets to the UE that may have been buffered for this PDU Session.
  • Step 3 If Request Type in step 3 indicates neither "Emergency Request” nor "Existing Emergency PDU Session” and, if the SMF has not yet registered for this PDU Session, then the SMF registers with the UDM using Nudm_UECM_Registration (SUPI, DNN, S-NSSAI, PDU Session ID, SMF Identity, Serving PLMN ID, [NID]) for a given PDU Session.
  • the UDM stores following information: SUPI, SMF identity and the associated DNN, S-NSSAI, PDU Session ID and Serving Network (PLMN ID, [NID], see clause 5.18 of TS 23.501 [2]).
  • the UDM may further store this information in UDR by Nudr DM Update (SUPI, Subscription Data, UE context in SMF data).
  • the SMF may register in the UDM using Nudm UECM Regi strati on (SUPI, PDU Session ID, SMF identity, Indication of Emergency Services) for a given PDU Session that is applicable for emergency services.
  • the UDM shall store the applicable PDU Session for Emergency services.
  • the SMF shall not register in the UDM for a given PDU Session.
  • SMF to AMF Nsmf_PDUSession_UpdateSMContext Response (Cause).
  • the SMF may subscribe to the UE mobility event notification from the AMF (e.g. location reporting, UE moving into or out of Area Of Interest), after this step by invoking Namf_EventExposure_Subscribe service operation as specified in clause 5.2.2.3.2.
  • the SMF subscribes to the UE moving into or out of LADN service area event notification by providing the LADN DNN as an indicator for the Area Of Interest (see clause 5.6.5 and 5.6.11 of TS 23.501 [2]).
  • the SMF informs the AMF by invoking Nsmf_PDUSession_SMContextStatusNotify (Release).
  • the SMF also releases any N4 session(s) created, any PDU Session address if allocated (e.g. IP address) and releases the association with PCF, if any. In this case, step 19 is skipped.
  • SMF to UE In the case of PDU Session Type IPv6 or IPv4v6, the SMF generates an IPv6 Router Advertisement and sends it to the UE. If Control Plane CIoT 5GS Optimisation is enabled for this PDU Session the SMF sends the IPv6 Router Advertisement via the AMF for transmission to the UE using the Mobile Terminated Data Transport in Control Plane CIoT 5GS Optimisation procedures (see clause 4.24.2), otherwise the SMF sends the IPv6 Router Advertisement via N4 and the UPF.
  • SMF informs PCF that a 5GS Bridge information is available.
  • SMF also includes the port number of the DS-TT Ethernet port, MAC address of the DS-TT Ethernet port, 5GS Bridge ID, Port Management Information Container and UE-DS-TT Residence Time as provided by the UE.
  • AF calculates the bridge delay for each port pair, e.g. composed of DS-TT Ethernet port and NW-TT Ethernet port, using the UE-DS-TT Residence Time for all NW-TT Ethernet port(s) serving the 5GS Bridge indicated by the 5GS Bridge ID.
  • the SMF may inform PCF that a manageable NW-TT Ethernet port has been detected. If SMF received a Port Management Information Container from the UPF, then SMF provides the Port Management Information Container to the PCF as described in clause 5.28.3.2 of TS 23.501 [2],
  • the SMF shall perform the following:
  • the SMF unsubscribes to the modifications of Session Management Subscription data for the corresponding (SUPI, DNN, S-NSSAI of the HPLMN), using Nudm_SDM_Unsub scribe (SUPI, Session Management Subscription data, DNN, S-NSSAI of the HPLMN), if the SMF is no more handling a PDU Session of the UE for this (DNN, S-NSSAI of the HPLMN).
  • the UDM may unsubscribe to the modification notification from UDR by Nudr DM Unsubscribe (SUPI, Subscription Data, Session Management Subscription data, S-NSSAI of the HPLMN, DNN).
  • Figure 15 illustrates an example technique 1500 related to identity management in fifth generation systems, in accordance with various embodiments.
  • the technique may be performed by an electronic device in a 5G network.
  • the electronic device may be, for example, an electronic device that implements an AF entity in the 5G network.
  • the technique 1500 may include generating, at 1505, an AF request that includes an indication of an associated entity of a UE or an eRG that is to be added to the network.
  • the associated entity may be, e.g., an entity that does not have an existing subscription to the 5G network.
  • the associated entity may be a PRAS or a PIN entity.
  • the AF request may be, e.g., a Nnef_ServiceParameter request message.
  • the technique 1500 may further include transmitting, at 1510, the indication of the associated entity to a PCF via a NEF of the 5G network.
  • Figure 16 illustrates an alternative example technique 1600 related to identity management in fifth generation systems, in accordance with various embodiments.
  • the technique may be performed by an electronic device of a 5G network such as a gateway UE or an eRG.
  • the technique 1600 may include identifying, at 1605, one or more capabilities of the electronic device, wherein the one or more capabilities are related to federated identity services of the 5G network.
  • the one or more capabilities may be, for example, data network proxy or DN-AAA.
  • the technique 1600 may further include generating, at 1610, a registration request message related to the one or more capabilities.
  • the technique 1600 may further include transmitting, at 1615, the registration request message to an entity of a core network of the 5G network.
  • the entity may be, for example, an AMF of the core network.
  • example techniques 1500 and 1600 are intended as examples of some embodiments of the present disclosure. Other embodiments may include more or fewer elements, different elements, elements in a different order than depicted, etc. Other embodiments may vary.
  • FIGS 17-19 illustrate various systems, devices, and components that may implement aspects of disclosed embodiments.
  • FIG 17 illustrates a network 1700 in accordance with various embodiments.
  • the network 1700 may operate in a manner consistent with 3GPP technical specifications for LTE or 5G/NR systems.
  • 3GPP technical specifications for LTE or 5G/NR systems 3GPP technical specifications for LTE or 5G/NR systems.
  • the example embodiments are not limited in this regard and the described embodiments may apply to other networks that benefit from the principles described herein, such as future 3GPP systems, or the like.
  • the network 1700 may include a UE 1702, which may include any mobile or non-mobile computing device designed to communicate with a RAN 1704 via an over-the-air connection.
  • the UE 1702 may be communicatively coupled with the RAN 1704 by a Uu interface.
  • the UE 1702 may be, but is not limited to, a smartphone, tablet computer, wearable computer device, desktop computer, laptop computer, in-vehicle infotainment, in-car entertainment device, instrument cluster, head-up display device, onboard diagnostic device, dashtop mobile equipment, mobile data terminal, electronic engine management system, electronic/engine control unit, electronic/engine control module, embedded system, sensor, microcontroller, control module, engine management system, networked appliance, machine-type communication device, M2M or D2D device, loT device, etc.
  • the network 1700 may include a plurality of UEs coupled directly with one another via a sidelink interface.
  • the UEs may be M2M/D2D devices that communicate using physical sidelink channels such as, but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc.
  • the UE 1702 may additionally communicate with an AP 1706 via an over-the-air connection.
  • the AP 1706 may manage a WLAN connection, which may serve to offload some/all network traffic from the RAN 1704.
  • the connection between the UE 1702 and the AP 1706 may be consistent with any IEEE 802.11 protocol, wherein the AP 1706 could be a wireless fidelity (Wi-Fi®) router.
  • the UE 1702, RAN 1704, and AP 1706 may utilize cellular- WLAN aggregation (for example, LWA/LWIP).
  • Cellular- WLAN aggregation may involve the UE 1702 being configured by the RAN 1704 to utilize both cellular radio resources and WLAN resources.
  • the RAN 1704 may include one or more access nodes, for example, AN 1708.
  • AN 1708 may terminate air-interface protocols for the UE 1702 by providing access stratum protocols including RRC, PDCP, RLC, MAC, and LI protocols. In this manner, the AN 1708 may enable data/voice connectivity between CN 1720 and the UE 1702.
  • the AN 1708 may be implemented in a discrete device or as one or more software entities running on server computers as part of, for example, a virtual network, which may be referred to as a CRAN or virtual baseband unit pool.
  • the AN 1708 be referred to as a BS, gNB, RAN node, eNB, ng-eNB, NodeB, RSU, TRxP, TRP, etc.
  • the AN 1708 may be a macrocell base station or a low power base station for providing femtocells, picocells or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.
  • the RAN 1704 may be coupled with one another via an X2 interface (if the RAN 1704 is an LTE RAN) or an Xn interface (if the RAN 1704 is a 5G RAN).
  • the X2/Xn interfaces which may be separated into control/user plane interfaces in some embodiments, may allow the ANs to communicate information related to handovers, data/context transfers, mobility, load management, interference coordination, etc.
  • the ANs of the RAN 1704 may each manage one or more cells, cell groups, component carriers, etc. to provide the UE 1702 with an air interface for network access.
  • the UE 1702 may be simultaneously connected with a plurality of cells provided by the same or different ANs of the RAN 1704.
  • the UE 1702 and RAN 1704 may use carrier aggregation to allow the UE 1702 to connect with a plurality of component carriers, each corresponding to a Pcell or Scell.
  • a first AN may be a master node that provides an MCG and a second AN may be secondary node that provides an SCG.
  • the first/second ANs may be any combination of eNB, gNB, ng-eNB, etc.
  • the RAN 1704 may provide the air interface over a licensed spectrum or an unlicensed spectrum.
  • the nodes may use LAA, eLAA, and/or feLAA mechanisms based on CA technology with PCells/Scells.
  • the nodes Prior to accessing the unlicensed spectrum, the nodes may perform medium/carrier-sensing operations based on, for example, a listen-before-talk (LBT) protocol.
  • LBT listen-before-talk
  • the UE 1702 or AN 1708 may be or act as a RSU, which may refer to any transportation infrastructure entity used for V2X communications.
  • An RSU may be implemented in or by a suitable AN or a stationary (or relatively stationary) UE.
  • An RSU implemented in or by: a UE may be referred to as a “UE-type RSU”; an eNB may be referred to as an “eNB-type RSU”; a gNB may be referred to as a “gNB-type RSU”; and the like.
  • an RSU is a computing device coupled with radio frequency circuitry located on a roadside that provides connectivity support to passing vehicle UEs.
  • the RSU may also include internal data storage circuitry to store intersection map geometry, traffic statistics, media, as well as applications/software to sense and control ongoing vehicular and pedestrian traffic.
  • the RSU may provide very low latency communications required for high speed events, such as crash avoidance, traffic warnings, and the like. Additionally or alternatively, the RSU may provide other cellular/WLAN communications services.
  • the components of the RSU may be packaged in a weatherproof enclosure suitable for outdoor installation, and may include a network interface controller to provide a wired connection (e.g., Ethernet) to a traffic signal controller or a backhaul network.
  • the RAN 1704 may be an LTE RAN 1710 with eNBs, for example, eNB 1712.
  • the LTE RAN 1710 may provide an LTE air interface with the following characteristics: SCS of 15 kHz; CP-OFDM waveform for DL and SC-FDMA waveform for UL; turbo codes for data and TBCC for control; etc.
  • the LTE air interface may rely on CSI-RS for CSI acquisition and beam management; PDSCH/PDCCH DMRS for PDSCH/PDCCH demodulation; and CRS for cell search and initial acquisition, channel quality measurements, and channel estimation for coherent demodulation/detection at the UE.
  • the LTE air interface may operating on sub-6 GHz bands.
  • the RAN 1704 may be an NG-RAN 1714 with gNBs, for example, gNB 1716, or ng-eNBs, for example, ng-eNB 1718.
  • the gNB 1716 may connect with 5G-enabled UEs using a 5GNR interface.
  • the gNB 1716 may connect with a 5G core through an NG interface, which may include an N2 interface or an N3 interface.
  • the ng-eNB 1718 may also connect with the 5G core through an NG interface, but may connect with a UE via an LTE air interface.
  • the gNB 1716 and the ng-eNB 1718 may connect with each other over an Xn interface.
  • the NG interface may be split into two parts, an NG user plane (NG-U) interface, which carries traffic data between the nodes of the NG-RAN 1714 and a UPF 1748 (e.g., N3 interface), and an NG control plane (NG-C) interface, which is a signaling interface between the nodes of the NG-RAN1714 and an AMF 1744 (e.g., N2 interface).
  • NG-U NG user plane
  • N-C NG control plane
  • the NG-RAN 1714 may provide a 5G-NR air interface with the following characteristics: variable SCS; CP-OFDM for DL, CP-OFDM and DFT-s-OFDM for UL; polar, repetition, simplex, and Reed-Muller codes for control and LDPC for data.
  • the 5G-NR air interface may rely on CSI-RS, PDSCH/PDCCH DMRS similar to the LTE air interface.
  • the 5G-NR air interface may not use a CRS, but may use PBCH DMRS for PBCH demodulation; PTRS for phase tracking for PDSCH; and tracking reference signal for time tracking.
  • the 5G-NR air interface may operating on FR1 bands that include sub-6 GHz bands or FR2 bands that include bands from 24.25 GHz to 52.6 GHz.
  • the 5G-NR air interface may include an SSB that is an area of a downlink resource grid that includes PSS/SSS/PBCH.
  • the 5G-NR air interface may utilize BWPs for various purposes.
  • BWP can be used for dynamic adaptation of the SCS.
  • the UE 1702 can be configured with multiple BWPs where each BWP configuration has a different SCS. When a BWP change is indicated to the UE 1702, the SCS of the transmission is changed as well.
  • Another use case example of BWP is related to power saving.
  • multiple BWPs can be configured for the UE 1702 with different amount of frequency resources (for example, PRBs) to support data transmission under different traffic loading scenarios.
  • a BWP containing a smaller number of PRBs can be used for data transmission with small traffic load while allowing power saving at the UE 1702 and in some cases at the gNB 1716.
  • a BWP containing a larger number of PRBs can be used for scenarios with higher traffic load.
  • the RAN 1704 is communicatively coupled to CN 1720 that includes network elements to provide various functions to support data and telecommunications services to customers/subscribers (for example, users of UE 1702).
  • the components of the CN 1720 may be implemented in one physical node or separate physical nodes.
  • NFV may be utilized to virtualize any or all of the functions provided by the network elements of the CN 1720 onto physical compute/storage resources in servers, switches, etc.
  • a logical instantiation of the CN 1720 may be referred to as a network slice, and a logical instantiation of a portion of the CN 1720 may be referred to as a network sub-slice.
  • the CN 1720 may be an LTE CN 1722, which may also be referred to as an EPC.
  • the LTE CN 1722 may include MME 1724, SGW 1726, SGSN 1728, HSS 1730, PGW 1732, and PCRF 1734 coupled with one another over interfaces (or “reference points”) as shown. Functions of the elements of the LTE CN 1722 may be briefly introduced as follows.
  • the MME 1724 may implement mobility management functions to track a current location of the UE 1702 to facilitate paging, bearer activation/deactivation, handovers, gateway selection, authentication, etc.
  • the SGW 1726 may terminate an SI interface toward the RAN and route data packets between the RAN and the LTE CN 1722.
  • the SGW 1726 may be a local mobility anchor point for inter-RAN node handovers and also may provide an anchor for inter-3 GPP mobility. Other responsibilities may include lawful intercept, charging, and some policy enforcement.
  • the SGSN 1728 may track a location of the UE 1702 and perform security functions and access control. In addition, the SGSN 1728 may perform inter-EPC node signaling for mobility between different RAT networks; PDN and S-GW selection as specified by MME 1724; MME selection for handovers; etc.
  • the S3 reference point between the MME 1724 and the SGSN 1728 may enable user and bearer information exchange for inter-3 GPP access network mobility in idle/active states.
  • the HSS 1730 may include a database for network users, including subscription-related information to support the network entities’ handling of communication sessions.
  • the HSS 1730 can provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, etc.
  • An S6a reference point between the HSS 1730 and the MME 1724 may enable transfer of subscription and authentication data for authenticating/authorizing user access to the LTE CN 1720.
  • the PGW 1732 may terminate an SGi interface toward a data network (DN) 1736 that may include an application/content server 1738.
  • the PGW 1732 may route data packets between the LTE CN 1722 and the data network 1736.
  • the PGW 1732 may be coupled with the SGW 1726 by an S5 reference point to facilitate user plane tunneling and tunnel management.
  • the PGW 1732 may further include a node for policy enforcement and charging data collection (for example, PCEF).
  • the SGi reference point between the PGW 1732 and the data network 17 36 may be an operator external public, a private PDN, or an intra-operator packet data network, for example, for provision of IMS services.
  • the PGW 1732 may be coupled with a PCRF 1734 via a Gx reference point.
  • the PCRF 1734 is the policy and charging control element of the LTE CN 1722.
  • the PCRF 1734 may be communicatively coupled to the app/content server 1738 to determine appropriate QoS and charging parameters for service flows.
  • the PCRF 1732 may provision associated rules into a PCEF (via Gx reference point) with appropriate TFT and QCI.
  • the CN 1720 may be a 5GC 1740.
  • the 5GC 1740 may include an AUSF 1742, AMF 1744, SMF 1746, UPF 1748, NSSF 1750, NEF 1752, NRF 1754, PCF 1756, UDM 1758, and AF 1760 coupled with one another over interfaces (or “reference points”) as shown.
  • Functions of the elements of the 5GC 1740 may be briefly introduced as follows.
  • the AUSF 1742 may store data for authentication of UE 1702 and handle authentication- related functionality.
  • the AUSF 1742 may facilitate a common authentication framework for various access types.
  • the AUSF 1742 may exhibit an Nausf service-based interface.
  • the AMF 1744 may allow other functions of the 5GC 1740 to communicate with the UE 1702 and the RAN 1704 and to subscribe to notifications about mobility events with respect to the UE 1702.
  • the AMF 1744 may be responsible for registration management (for example, for registering UE 1702), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization.
  • the AMF 1744 may provide transport for SM messages between the UE 1702 and the SMF 1746, and act as a transparent proxy for routing SM messages.
  • AMF 1744 may also provide transport for SMS messages between UE 1702 and an SMSF.
  • AMF 1744 may interact with the AUSF 1742 and the UE 1702 to perform various security anchor and context management functions.
  • AMF 1744 may be a termination point of a RAN CP interface, which may include or be an N2 reference point between the RAN 1704 and the AMF 1744; and the AMF 1744 may be a termination point of NAS (Nl) signaling, and perform NAS ciphering and integrity protection.
  • AMF 1744 may also support NAS signaling with the UE 1702 over an N3 IWF interface.
  • the SMF 1746 may be responsible for SM (for example, session establishment, tunnel management between UPF 1748 and AN 1708); UE IP address allocation and management (including optional authorization); selection and control of UP function; configuring traffic steering at UPF 1748 to route traffic to proper destination; termination of interfaces toward policy control functions; controlling part of policy enforcement, charging, and QoS; lawful intercept (for SM events and interface to LI system); termination of SM parts of NAS messages; downlink data notification; initiating AN specific SM information, sent via AMF 1744 overN2 to AN 1708; and determining SSC mode of a session.
  • SM for example, session establishment, tunnel management between UPF 1748 and AN 1708
  • UE IP address allocation and management including optional authorization
  • selection and control of UP function configuring traffic steering at UPF 1748 to route traffic to proper destination
  • termination of interfaces toward policy control functions controlling part of policy enforcement, charging, and QoS
  • lawful intercept for SM events and interface to LI system
  • SM may refer to management of a PDU session
  • a PDU session or “session” may refer to a PDU connectivity service that provides or enables the exchange of PDUs between the UE 1702 and the data network 1736.
  • the UPF 1748 may act as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point of interconnect to data network 1736, and a branching point to support multi-homed PDU session.
  • the UPF 1748 may also perform packet routing and forwarding, perform packet inspection, enforce the user plane part of policy rules, lawfully intercept packets (UP collection), perform traffic usage reporting, perform QoS handling for a user plane (e.g., packet filtering, gating, UL/DL rate enforcement), perform uplink traffic verification (e.g., SDF- to-QoS flow mapping), transport level packet marking in the uplink and downlink, and perform downlink packet buffering and downlink data notification triggering.
  • UPF 1748 may include an uplink classifier to support routing traffic flows to a data network.
  • the NSSF 1750 may select a set of network slice instances serving the UE 1702.
  • the NSSF 1750 may also determine allowed NSSAI and the mapping to the subscribed S-NSSAIs, if needed.
  • the NSSF 1750 may also determine the AMF set to be used to serve the UE 1702, or a list of candidate AMFs based on a suitable configuration and possibly by querying the NRF 1754.
  • the selection of a set of network slice instances for the UE 1702 may be triggered by the AMF 1744 with which the UE 1702 is registered by interacting with the NSSF 1750, which may lead to a change of AMF.
  • the NSSF 1750 may interact with the AMF 1744 via an N22 reference point; and may communicate with another NSSF in a visited network via an N31 reference point (not shown). Additionally, the NSSF 1750 may exhibit an Nnssf service-based interface.
  • the NEF 1752 may securely expose services and capabilities provided by 3 GPP network functions for third party, internal exposure/re-exposure, AFs (e.g., AF 1760), edge computing or fog computing systems, etc.
  • the NEF 1752 may authenticate, authorize, or throttle the AFs.
  • NEF 1752 may also translate information exchanged with the AF 1760 and information exchanged with internal network functions. For example, the NEF 1752 may translate between an AF-Service-Identifier and an internal 5GC information.
  • NEF 1752 may also receive information from other NFs based on exposed capabilities of other NFs. This information may be stored at the NEF 1752 as structured data, or at a data storage NF using standardized interfaces. The stored information can then be re-exposed by the NEF 1752 to other NFs and AFs, or used for other purposes such as analytics. Additionally, the NEF 1752 may exhibit an Nnef servicebased interface.
  • the NRF 1754 may support service discovery functions, receive NF discovery requests from NF instances, and provide the information of the discovered NF instances to the NF instances. NRF 1754 also maintains information of available NF instances and their supported services. As used herein, the terms “instantiate,” “instantiation,” and the like may refer to the creation of an instance, and an “instance” may refer to a concrete occurrence of an object, which may occur, for example, during execution of program code. Additionally, the NRF 1754 may exhibit the Nnrf service-based interface.
  • the PCF 1756 may provide policy rules to control plane functions to enforce them, and may also support unified policy framework to govern network behavior.
  • the PCF 1756 may also implement a front end to access subscription information relevant for policy decisions in a UDR of the UDM 1758.
  • the PCF 1756 exhibit an Npcf service-based interface.
  • the UDM 1758 may handle subscription-related information to support the network entities’ handling of communication sessions, and may store subscription data of UE 1702. For example, subscription data may be communicated via an N8 reference point between the UDM 1758 and the AMF 1744.
  • the UDM 1758 may include two parts, an application front end and a UDR.
  • the UDR may store subscription data and policy data for the UDM 1758 and the PCF 1756, and/or structured data for exposure and application data (including PFDs for application detection, application request information for multiple UEs 1702) for the NEF 1752.
  • the Nudr service-based interface may be exhibited by the UDR 221 to allow the UDM 1758, PCF 1756, and NEF 1752 to access a particular set of the stored data, as well as to read, update (e.g., add, modify), delete, and subscribe to notification of relevant data changes in the UDR.
  • the UDM may include a UDM- FE, which is in charge of processing credentials, location management, subscription management and so on. Several different front ends may serve the same user in different transactions.
  • the UDM-FE accesses subscription information stored in the UDR and performs authentication credential processing, user identification handling, access authorization, registration/mobility management, and subscription management.
  • the UDM 1758 may exhibit the Nudm service-based interface.
  • the AF 1760 may provide application influence on traffic routing, provide access to NEF, and interact with the policy framework for policy control.
  • the 5GC 1740 may enable edge computing by selecting operator/3 rd party services to be geographically close to a point that the UE 1702 is attached to the network. This may reduce latency and load on the network.
  • the 5GC 1740 may select a UPF 1748 close to the UE 1702 and execute traffic steering from the UPF 1748 to data network 1736 via the N6 interface. This may be based on the UE subscription data, UE location, and information provided by the AF 1760. In this way, the AF 1760 may influence UPF (re)selection and traffic routing.
  • the network operator may permit AF 1760 to interact directly with relevant NFs. Additionally, the AF 1760 may exhibit an Naf service-based interface.
  • the data network 1736 may represent various network operator services, Internet access, or third party services that may be provided by one or more servers including, for example, application/content server 1738.
  • FIG. 18 schematically illustrates a wireless network 1800 in accordance with various embodiments.
  • the wireless network 1800 may include a UE 1802 in wireless communication with an AN 1804.
  • the UE 1802 and AN 1804 may be similar to, and substantially interchangeable with, like-named components described elsewhere herein.
  • the UE 1802 may be communicatively coupled with the AN 1804 via connection 1806.
  • the connection 1806 is illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols such as an LTE protocol or a 5G NR protocol operating at mmWave or sub-6GHz frequencies.
  • the UE 1802 may include a host platform 1808 coupled with a modem platform 1810.
  • the host platform 1808 may include application processing circuitry 1812, which may be coupled with protocol processing circuitry 1814 of the modem platform 1810.
  • the application processing circuitry 1812 may run various applications for the UE 1802 that source/sink application data.
  • the application processing circuitry 1812 may further implement one or more layer operations to transmit/receive application data to/from a data network. These layer operations may include transport (for example UDP) and Internet (for example, IP) operations
  • the protocol processing circuitry 1814 may implement one or more of layer operations to facilitate transmission or reception of data over the connection 1806.
  • the layer operations implemented by the protocol processing circuitry 1814 may include, for example, MAC, RLC, PDCP, RRC and NAS operations.
  • the modem platform 1810 may further include digital baseband circuitry 1816 that may implement one or more layer operations that are “below” layer operations performed by the protocol processing circuitry 1814 in a network protocol stack. These operations may include, for example, PHY operations including one or more of HARQ-ACK functions, scrambling/descrambling, encoding/decoding, layer mapping/de-mapping, modulation symbol mapping, received symbol/bit metric determination, multi-antenna port precoding/decoding, which may include one or more of space-time, space-frequency or spatial coding, reference signal generation/detection, preamble sequence generation and/or decoding, synchronization sequence generation/detection, control channel signal blind decoding, and other related functions.
  • PHY operations including one or more of HARQ-ACK functions, scrambling/descrambling, encoding/decoding, layer mapping/de-mapping, modulation symbol mapping, received symbol/bit metric determination, multi-antenna port precoding/decoding, which may
  • the modem platform 1810 may further include transmit circuitry 1818, receive circuitry 1820, RF circuitry 1822, and RF front end (RFFE) 1824, which may include or connect to one or more antenna panels 1826.
  • the transmit circuitry 1818 may include a digital -to-analog converter, mixer, intermediate frequency (IF) components, etc.
  • the receive circuitry 1820 may include an analog-to-digital converter, mixer, IF components, etc.
  • the RF circuitry 1822 may include a low-noise amplifier, a power amplifier, power tracking components, etc.
  • RFFE 1824 may include filters (for example, surface/bulk acoustic wave filters), switches, antenna tuners, beamforming components (for example, phase-array antenna components), etc.
  • transmit/receive components may be specific to details of a specific implementation such as, for example, whether communication is TDM or FDM, in mmWave or sub-6 gHz frequencies, etc.
  • the transmit/receive components may be arranged in multiple parallel transmit/receive chains, may be disposed in the same or different chips/modules, etc.
  • the protocol processing circuitry 1814 may include one or more instances of control circuitry (not shown) to provide control functions for the transmit/receive components.
  • a UE reception may be established by and via the antenna panels 1826, RFFE 1824, RF circuitry 1822, receive circuitry 1820, digital baseband circuitry 1816, and protocol processing circuitry 1814.
  • the antenna panels 1826 may receive a transmission from the AN 1804 by receive-beamforming signals received by a plurality of antennas/antenna elements of the one or more antenna panels 1826.
  • a UE transmission may be established by and via the protocol processing circuitry 1814, digital baseband circuitry 1816, transmit circuitry 1818, RF circuitry 1822, RFFE 1824, and antenna panels 1826.
  • the transmit components of the UE 1804 may apply a spatial filter to the data to be transmitted to form a transmit beam emitted by the antenna elements of the antenna panels 1826.
  • the AN 1804 may include a host platform 1828 coupled with a modem platform 1830.
  • the host platform 1828 may include application processing circuitry 1832 coupled with protocol processing circuitry 1834 of the modem platform 1830.
  • the modem platform may further include digital baseband circuitry 1836, transmit circuitry 1838, receive circuitry 1840, RF circuitry 1842, RFFE circuitry 1844, and antenna panels 1846.
  • the components of the AN 1804 may be similar to and substantially interchangeable with like- named components of the UE 1802.
  • the components of the AN 1808 may perform various logical functions that include, for example, RNC functions such as radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling.
  • Figure 19 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein.
  • Figure 19 shows a diagrammatic representation of hardware resources 1900 including one or more processors (or processor cores) 1910, one or more memory/storage devices 1920, and one or more communication resources 1930, each of which may be communicatively coupled via a bus 1940 or other interface circuitry.
  • a hypervisor 1902 may be executed to provide an execution environment for one or more network slices/sub-slices to utilize the hardware resources 1900.
  • the processors 1910 may include, for example, a processor 1912 and a processor 1914.
  • the processors 1910 may be, for example, a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a DSP such as a baseband processor, an ASIC, an FPGA, a radiofrequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.
  • CPU central processing unit
  • RISC reduced instruction set computing
  • CISC complex instruction set computing
  • GPU graphics processing unit
  • DSP such as a baseband processor, an ASIC, an FPGA, a radiofrequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.
  • the memory/storage devices 1920 may include main memory, disk storage, or any suitable combination thereof.
  • the memory/storage devices 1920 may include, but are not limited to, any type of volatile, non-volatile, or semi-volatile memory such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), Flash memory, solid-state storage, etc.
  • DRAM dynamic random access memory
  • SRAM static random access memory
  • EPROM erasable programmable read-only memory
  • EEPROM electrically erasable programmable read-only memory
  • Flash memory solid-state storage, etc.
  • the communication resources 1930 may include interconnection or network interface controllers, components, or other suitable devices to communicate with one or more peripheral devices 1904 or one or more databases 1906 or other network elements via a network 1908.
  • the communication resources 1930 may include wired communication components (e.g., for coupling via USB, Ethernet, etc.), cellular communication components, NFC components, Bluetooth® (or Bluetooth® Low Energy) components, Wi-Fi® components, and other communication components.
  • Instructions 1950 may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors 1910 to perform any one or more of the methodologies discussed herein.
  • the instructions 1950 may reside, completely or partially, within at least one of the processors 1910 (e.g., within the processor’s cache memory), the memory/storage devices 1920, or any suitable combination thereof.
  • any portion of the instructions 1950 may be transferred to the hardware resources 1900 from any combination of the peripheral devices 1904 or the databases 1906. Accordingly, the memory of processors 1910, the memory/storage devices 1920, the peripheral devices 1904, and the databases 1906 are examples of computer-readable and machine-readable media.
  • At least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, and/or methods as set forth in the example section below.
  • the baseband circuitry as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below.
  • circuitry associated with a UE, base station, network element, etc. as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below in the example section.
  • Example 1 may include the method for enabling federated identity management in 5G system.
  • Example 2 may include the method of example 1 and/or some other example herein, whereby the operator of the 5G system acts as an identifier provider (IdP) responsible for user authentication of services provided in different data network domains including cloud, personal loT networks, residential networks.
  • IdP identifier provider
  • Example 3 may include the method of example 2 and/or some other example herein, whereby, for data network domain in residential network, a residential gateway (eRG) interconnects two networks and relay the traffic between residential network and 5G network and provides connectivity to 5G network for associated entity of small indoor base station (PRAS) and non-3GPP devices.
  • a residential gateway eRG interconnects two networks and relay the traffic between residential network and 5G network and provides connectivity to 5G network for associated entity of small indoor base station (PRAS) and non-3GPP devices.
  • PRAS small indoor base station
  • Example 4 may include the method of example 3 and/or some other example herein, whereby the authenticated/authorized eRG adds the information of an associated entity of the eRG to the 5G network, in which the associated entity is regarded as a user with user identity associated to the eRG subscription.
  • Example 5 may include the method of example 4 and/or some other example herein, whereby each associated entity of the eRG is registered as a data network domain and the eRG acts as a data network proxy for forwarding traffics between the 5G network and the data network domain of the associated entity.
  • Example 6 may iclude the method of example 5 and/or some other example herein, whereby when the operator authenticates the user identity of the associated non-3GPP device(s) or PRAS(s) of the eRG, the trust can be further established between the non-3GPP device/PRAS and eRG.
  • Example 7 may include the method of example 6 and/or some other example herein, whereby the non-3GPP device/PRAS continues to create and register user identities to the 5G network for their associated entities including UEs connected to the PRAS and the applications running on the non-3GPP device or connected to it, in which the next level of trust can be further established between the non-3GPP device/PRAS and associated entities.
  • Example 8 may include the method of example 2 and/or some other example herein, whereby for data network domain in personal loT network (PIN), a UE acting as a gateway interconnects two networks and relay the traffic between residential network and 5G network and provides connectivity to 5G network for associated entity of things including human users, non-3GPP devices, applications running on the UE or connected to the UE.
  • PIN personal loT network
  • Examle 9 may include the method of example 8 and/or some other example herein, whereby the authenticated/authorized UE adds the information of an associated entity of the UE to the 5G network, in which the associated entity is regarded as a user with user identity associated to the UE subscription.
  • Example 10 may include the method of example 9 and/or some other example herein, whereby each associated entity of the UE is registered as a data network domain and the UE acts as a data network proxy for forwarding traffics between the 5G network and the data network domain of the associated entity.
  • Example 11 may include the method of example 10 and/or some other example herein, whereby when the operator authenticates the user identity of the associated entities of the UE, the trust can be further established between associated entity and the UE.
  • Example 12 may include the method of examples 10 or example 7 and/or some other example herein, whereby when an associated entity of the UE as a human user is authenticated by the 5G network, the human user using authenticated/authorized UE can access authorized services provided by different authorized data network domains in the clouds, PIN, and residential network.
  • Exampel 13 may include the method of example 10 or example 7 and/or some other example herein, whereby for allowing an authorized UE to access the service in data network domain of PIN or residential, the authorized UE is configured with information of the data network domains via UE configuration update procedure for transparent UE Policy delivery, which is triggered by PCF in 5G network for updating the following set of information for an authorized data network domain:
  • Authorized DNN(s) of the data network domains e.g. PIN, Residential network, Allowed S-NSSA(s) of each authorized DNN, Authorized user identifier(s) of the application(s) with user identit(ies) of each authorized DNN.
  • Example 14 may include the method of example 10 or example 7 and/or some other example herein, whereby the eRG/gateway UE in PIN enables support of Data network proxy and NAT in 5G system.
  • Example 15 may include the method of example 14 and/or some other example herein, whereby eRG/gateway UE subscription includes federated Identity services of 5G network for handling user identities, user profiles, user authentication, service authorization, access control, etc.
  • Example 16 may include the method of example 15 and/or some other example herein, whereby eRG/gateway UE capabilities include Data network proxy and DN-AAA capabilities.
  • Example 17 may include the method of example 16 and/or some other example herein, whereby eRG/gateway UE’s registration procedure indicatingeRG/gateway UE capabilities in the registration request message.
  • Example 18 may include the method of example 17 and/or some other example herein, whereby the eRG/gateway UE uses PDU session modification request procedure to update DN- AAA address information at eRG by indicating a new IE in the request message.
  • Example 19 may include the method of example 18 and/or some other example herein, whereby when a new non-3GPP device or PRAS is discovered and connected to eRG/gateway UE, the eRG/gateway UE performs registration procedure to register the non-3GPP device or PRAS with user identities, the 5G network allocates DNN information for identifying the data network domain of the associated entity for the eRG/gateway UE.
  • Example 20 may iclude the method of example 19 and/or some other example herein, whereby the eRG/gateway UE transfers traffic of multiple data network domains for PIN and residential network and the eRG/gateway UE may determine to use the same or different PDU session for transferring traffic of multiple data network domains for PIN and residential.
  • Example 21 may iclude the method of example 20 and/or some other example herein, whereby if different PDU sessions are used for transporting user plane data for different data network domain of associated entity, the eRG/gateway UE uses PDU session request/modification procedure to provide/update the DNN information of the data network domain for the associated entities.
  • Example 22 may include the method of example 21 and/or some other example herein, whereby the eRG/gateway UE indicates one or more DNN(s) of data network domain(s) for the associated entity(es) in the new IE in the PDU session request/modification request message.
  • Example 23 may include the method of example 22 and/or some other example herein, whereby the SMF stores the mapping information between the PDU session ID and one or more DNN(s) of the data network domains for the associated entity of the eRG/gateway UE.
  • Example 24 may include the method of example 23 and/or some other example herein, whereby eRG/gateway UE acting as DN proxy sends a PDU session establishment request indicating the reliable connection for DN proxy and this PDU session is used for any DN related control plane traffic, e.g. authentication request/response messages.
  • Example 25 may include the method of example 1, and/or some other example herein, whereby the associated entity (non-3GPP device or PRAS) is connected and associated to the UE or eRG which is regarded as trusted 3GPP devices, the associated entity is dependent on the UE/eRG subscription.
  • the associated entity non-3GPP device or PRAS
  • Example 26 may include the method of example 25, and/or some other example herein, whereby the UE subscription includes the Federated Identity Management services for user centric management and authentication provided by the operator.
  • Example 27 may include the method of example 1, and/or some other example herein, whereby based on UE/eRG subscription and AF provisioned service specific parameter, the PCF performs data network domain configuration and configures user profiles for the associated entity.
  • Example 28 may include the method of example 27, and/or some other example herein, whereby the PCF creates the one or more user profiles of the associated entity.
  • Example 29 may include the method of example 28, and/or some other example herein, whereby the allocates at least one of the following information for identifying the data network domain of the associated entity: the DNN, subdomain name, and S-NSSAI. All these data network parameters can be used together to identify a data network service in the PIN/residential environment (CPN).
  • CPN PIN/residential environment
  • Example 30 may include the method of example 29, and/or some other example herein, whereby the PCF configures user policy containing information of user identifiers, data network configuration (e.g. DNN, subdomain name, and S-NSSAI), operator’s access control setting for Unified Access Control (used by the eRG to access 5G network for the associated entity), etc. as part of the UE/eRG policy for the associated entity (non-3GPP device, PRAS).
  • data network configuration e.g. DNN, subdomain name, and S-NSSAI
  • operator access control setting for Unified Access Control (used by the eRG to access 5G network for the associated entity), etc.
  • PRAS Non-3GPP device
  • Example 31 may include the method of example 30, and/or some other example herein, where by the PCF performs UE policy delivery
  • Example 32 may include the method for enabling federated identity management in 5G system.
  • Example 33 may include the method of example 32 and/or some other example herein, whereby 5G network supports automatic on boarding process for new associated entity of a UE/eRG (both are with PIN Element with Gateway Capability) and the associated entity is a non-3GPP device which does not have 3GPP subscription and 3GPP credentials and may or may not have 3 GPP capability.
  • Example 34 may include the method of example 33 and/or some other example herein, whereby the 5G network creates and manages a PIN identified by a PIN ID.
  • Example 35 may include the method of example 34 and/or some other example herein, whereby a PIN Element with Gateway Capability in a PIN can request 5G network to on board a PIN Element that is connected to it.
  • Example 36 may include the method of example 35 and/or some other example herein, whereby the 5G network supports suitable APIs for the third party (application server) to provide configuration information of a PIN Element connected to a PIN Element with Gateway Capability in a PIN.
  • Example 37 may include the method of example 36 and/or some other example herein, whereby the application server requests 5G network via AF to on board the PIN Element, in which the on boarding request from the UE, including the UE ID, PIN ID (if available) and the configuration information of the non-3GPP device.
  • Example 38 may include the method of example 37 and/or some other example herein, whereby the 5G network creates an identity that can uniquely identify the PIN Element and associates the PIN Element to the PIN Element with Gateway Capability for the PIN.
  • Example 39 may include the method of example 38 and/or some other example herein, whereby the 5G network creates the User Profile of the PIN Element and stored the User Profile at the MNOa with configuration information provided by the PIN Element via the UE.
  • Example 40 may include the method of example 39 and/or some other example herein, whereby if PIN ID is not available, the 5G network creates a PIN ID to uniquely identify the PIN and return the allocated PIN ID to the PIN Element with Gateway Capability for the PIN in the response message.
  • Example 41 may include the method of example 40 and/or some other example herein, whereby the 5G network sends notification message (including PIN ID, identity of the PIN Element, and authorization of the communications between the PIN Element with Gateway Capability and the PIN Element) to the PIN Element with Gateway Capability which requested to on boarding its associated non-3GPP device.
  • notification message including PIN ID, identity of the PIN Element, and authorization of the communications between the PIN Element with Gateway Capability and the PIN Element
  • Example 42 may include the method of example 41 and/or some other example herein, whereby the 5G network authenticates the identity of the first PIN Element within the PIN based on the User Profiles of the PIN Elements in the PIN and manages the authorization and the communication between the first PIN Element and other PIN Elements using PIN direct connection.
  • Example 43 may include the method of example 42 and/or some other example herein, whereby the 5G network configures and authorizes a PIN Element with Gateway Capability with PIN Element with Management Capability which can manage and configure management and configuration data of the PIN locally.
  • Example 44 may include the method of example 41 and/or some other example herein, whereby the User Profile contains the User Identifier and the configuration of the PIN Element.
  • Example 45 may include the method of example 44 and/or some other example herein, whereby the configuration of the PIN Element in the User profile contains: Specific configuration settings and parameters, e.g. active/inactive time, number of accesses, etc; Authorized communication methods, e.g. direct network connection, direct device connection, PIN direct connection (e.g. Bluetooth, WLAN, wireline); Authentication/authorization policy and access restriction policy to access the PIN Element or application running on the PIN Element; Credential for 5G network Authentication; Credential information of the authorized users for communicating with the PIN Element.
  • Specific configuration settings and parameters e.g. active/inactive time, number of accesses, etc
  • Authorized communication methods e.g. direct network connection, direct device connection, PIN direct connection (e.g. Bluetooth, WLAN, wireline); Authentication/authorization policy and access restriction policy to access the PIN Element or application running on the PIN Element; Credential for 5G network Authentication; Credential information of the authorized users for communicating
  • Example 46 may include the method of example 45 and/or some other example herein, whereby the PIN Element can have one or more User Profile (each is identified by different User Identifier).
  • Example 47 may include the method of example 46 and/or some other example herein, whereby for the same PIN Element, it can connect to two different gateways with PIN Element Gateway Capability, e.g. UE or eRG.
  • PIN Element Gateway Capability e.g. UE or eRG.
  • Example 48 may include the method of example 47 and/or some other exampel herein, whereby when the PIN Element connects to different gateways, it can apply different User Profiles associated to its User Identity and indicates User identifier and the corresponding credentials in the registration request message.
  • Example 49 may include the method of example 48 and/or some other example herein, whereby the 5G network authenticates the non-3GPP device/PIN Element based on the user identifier and the credentials indicated in the registration request message.
  • Example 50 may include the method of examples 39 and/or 49 and/or some other example herein, whereby for on boarding a PRAS (without 3GPP subscription and credentials), the 5G network allocates a PRAS ID.
  • Example 51 may include the method of example 50 and/or some other example herein, whereby the configuration information of the PRAS in the User Profile includes the PRAS radio capabilities (WLAN, wireline or 3 GPP radio capabilities and network capabilities.
  • the PRAS radio capabilities WLAN, wireline or 3 GPP radio capabilities and network capabilities.
  • Example 52 may include the method of example 51 and/or some other example herein, whereby if the PRAS supports 3GPP radio capabilities, it contains applicable settings, e.g. the carrier frequencies, and IAB capability (via eRG or gNB as donor IAB).
  • applicable settings e.g. the carrier frequencies, and IAB capability (via eRG or gNB as donor IAB).
  • Example 53 may include the method of example 52 and/or some other example herein, whereby if the PRAS supports 3 GPP network capabilities, it contains applicable settings, e.g. NAS for connecting to N3IWF.
  • Example 54 may include the method of example 38 and/or some other example herein, whereby the PIN Element sends the on boarding request to the application server is regarded as offering the permission to add the new associated PIN Element.
  • Example 55 may include the method of example 54 and/or some other example herein, whereby when the 5G network creates a PIN with a PIN ID. The corresponding PIN configuration is stored, which may be associated to the PIN Element with Gateway Capability.
  • Example 56 may include the method of example 55 and/or some other example herein, whereby based on the stored PIN information, if the permission of adding a new PIN Element for a PIN is needed from a second PIN Element, e.g. a UE, the 5G network sends a request message asking for the permission from the second PIN Element. With the permission, the 5G network continues on boarding process.
  • a second PIN Element e.g. a UE
  • Example 57 may include the method of example 56 and/or some other example herein, whereby if the second PIN Element rejects the permission request, the 5G network rejects the process to add the PIN Element and replies rejection cause in the response message to the PIN Element requesting for on boarding the PIN Element.
  • Example 58 may include the method of example 57 and/or some other example herein, whereby the permission request is send via NAS message or user plane traffic to the second PIN Element.
  • Example 59 may include a method to be performed by an electronic device in a fifth generation (5G) network, wherein the method comprises: generating, by the electronic device, an application function (AF) request that includes an indication of an associated entity of a user equipment (UE) or an evolved residential gateway (eRG) that is to be added to the network; and transmitting, by the electronic device, the indication of the associated entity to a Policy Control Function (PCF) via a network exposure function (NEF) of the 5G network.
  • AF application function
  • PCF Policy Control Function
  • NEF network exposure function
  • Example 60 may include the method of example 59, and/or some other example herein, wherein the associated entity is an entity that does not have an existing subscription to the 5G network.
  • Example 61 may include the method of any of examples 59-60, and/or some other example herein, wherein the electronic device implements an AF entity in the in the 5G network that generates that AF request.
  • Example 62 may include the method of any of examples 59-61, and/or some other example herein, wherein the AF request is a Nnef ServiceParameter request message.
  • Example 63 may include the method of any of examples 59-62, and/or some other example herein, wherein the associated entity is a premises radio access station (PRAS) or a personal internet of things (loT) network (PIN) entity.
  • Example 64 may include the method of any of examples 59-63, and/or some other example herein, wherein the indication includes one or more of a user description related to the associated entity, a service description related to the associated entity, service parameters related to the associated entity, and an indication of one or more target UEs related to the associated entity.
  • Example 65 may include the method of example 64, and/or some other example herein, wherein the user description includes one or more of a user type, a user identifier (ID), and a user profile.
  • the user description includes one or more of a user type, a user identifier (ID), and a user profile.
  • Example 66 may include the method of example 65, and/or some other example herein, wherein the user profile includes one or more of a user identifier, a list of authorized UEs, capability related to authentication support, information related to authentication or authorization policies, 5G network service settings and parameters, and data network parameters.
  • Example 67 may include the method of any of examples 59-66, and/or some other example herein, wherein the PCF is to create one or more user profiles related to the associated entity based on a subscription of the UE or the eRG and the indication.
  • Example 68 may include the method of example 67, and/or some other example herein, wherein a user profile of the one or more user profiles includes a DNN (Data Network Name) related to the associated entity, a subdomain name related to the associated entity, and a singlenetwork slice selection assistance information (S-NSSAI) related to the associated entity.
  • DNN Data Network Name
  • S-NSSAI singlenetwork slice selection assistance information
  • Example 69 may include a method to be performed by an electronic device in a fifth generation (5G) network, wherein the method comprises: identifying, by the electronic device, one or more capabilities of the electronic device, wherein the one or more capabilities are related to federated identity services of the 5G network; generating, by the electronic device, a registration request message related to the one or more capabilities; and transmitting, by the electronic device, the registration request message to an entity of a core network of the 5G network.
  • 5G fifth generation
  • Example 70 may include the method of example 69, and/or some other example herein, wherein the entity is an access and mobility management function (AMF) of a core network of the 5G network.
  • AMF access and mobility management function
  • Example 71 may include the method of any of examples 69-70, and/or some other example herein, wherein the one or more capabilities include data network proxy or direct network authentication, authorization, and accounting (DN-AAA).
  • the one or more capabilities include data network proxy or direct network authentication, authorization, and accounting (DN-AAA).
  • Example 72 may include the method of any of examples 69-71, and/or some other example herein, wherein the electronic device is a gateway user equipment (UE).
  • Example 73 may include the method of any of examples 69-72, and/or some other example herein, wherein the electronic device is an evolved residential gateway (eRG).
  • eRG evolved residential gateway
  • Example 74 may include the method of any of examples 69-73, and/or some other example herein, wherein the method further comprises: identifying, by the electronic device, updated direct network authentication, authorization, and accounting (DN-AAA) address information; generating, by the electronic device, a protocol data unit (PDU) session modification request message that includes an IE related to the updated DN-AAA address information; and transmitting, by the electronic device, the PDU session modification request message to the entity of the core netowork.
  • DNSAA direct network authentication, authorization, and accounting
  • Example 75 may include the method of any of examples 69-74, and/or some other example herein, wherein the method further comprises: identifying, by the electronic device, a new device that is communicatively coupled to the electronic device; and registering, by the electronic device, the new device with the entity of the core network.
  • Example 76 may include the method of example 75, and/or some other example herein, wherein the new device is a premises radio access station (PRAS) or a personal internet of things (loT) network (PIN) entity.
  • PRAS premises radio access station
  • LoT personal internet of things
  • PIN personal internet of things
  • Example 77 may include the method of any of examples 69-76, and/or some other example herein, further comprising: identifying, by the electronic device, a received UE configuration update message; and identifying, by the electronic device based on the UE configuration update message, a service domain of a personal internet of things (loT) network (PIN) entity or a residential network.
  • LoT personal internet of things
  • PIN personal internet of things
  • Example 78 may include the method of example 77, and/or some other example herein, wherein the UE configuration update message includes one or more of: an indication of one or more authorized domain network names (DNNs) of data network domains associated with the PIN entity or residential network; an indication of allowed single-network slice selection assistance information (S-NSSAIs) of respective ones of the DNNs; and an indication of authorized user identifiers of applications with user identities of respective ones of the DNNs.
  • DNNs authorized domain network names
  • S-NSSAIs single-network slice selection assistance information
  • Example 79 may include an apparatus comprising means to perform one or more elements of a method described in or related to any of examples 1-78, or any other method or process described herein.
  • Example 80 may include one or more non-transitory computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of a method described in or related to any of examples 1-78, or any other method or process described herein.
  • Example 81 may include an apparatus comprising logic, modules, or circuitry to perform one or more elements of a method described in or related to any of examples 1-78, or any other method or process described herein.
  • Example 82 may include a method, technique, or process as described in or related to any of examples 1-78, or portions or parts thereof.
  • Example 83 may include an apparatus comprising: one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples 1-78, or portions thereof.
  • Example 84 may include a signal as described in or related to any of examples 1-78, or portions or parts thereof.
  • Example 85 may include a datagram, packet, frame, segment, protocol data unit (PDU), or message as described in or related to any of examples 1-78, or portions or parts thereof, or otherwise described in the present disclosure.
  • PDU protocol data unit
  • Example 86 may include a signal encoded with data as described in or related to any of examples 1-78, or portions or parts thereof, or otherwise described in the present disclosure.
  • Example 87 may include a signal encoded with a datagram, packet, frame, segment, protocol data unit (PDU), or message as described in or related to any of examples 1-78, or portions or parts thereof, or otherwise described in the present disclosure.
  • PDU protocol data unit
  • Example 88 may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors is to cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples 1-78, or portions thereof.
  • Example 89 may include a computer program comprising instructions, wherein execution of the program by a processing element is to cause the processing element to carry out the method, techniques, or process as described in or related to any of examples 1-78, or portions thereof.
  • Example 90 may include a signal in a wireless network as shown and described herein.
  • Example 91 may include a method of communicating in a wireless network as shown and described herein.
  • Example 92 may include a system for providing wireless communication as shown and described herein.
  • Example 93 may include a device for providing wireless communication as shown and described herein.
  • circuitry refers to, is part of, or includes hardware components such as an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group), an Application Specific Integrated Circuit (ASIC), a field-programmable device (FPD) (e.g., a field-programmable gate array (FPGA), a programmable logic device (PLD), a complex PLD (CPLD), a high-capacity PLD (HCPLD), a structured ASIC, or a programmable SoC), digital signal processors (DSPs), etc., that are configured to provide the described functionality.
  • FPD field-programmable device
  • FPGA field-programmable gate array
  • PLD programmable logic device
  • CPLD complex PLD
  • HPLD high-capacity PLD
  • DSPs digital signal processors
  • the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality.
  • the term “circuitry” may also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) with the program code used to carry out the functionality of that program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuitry.
  • processor circuitry refers to, is part of, or includes circuitry capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations, or recording, storing, and/or transferring digital data.
  • Processing circuitry may include one or more processing cores to execute instructions and one or more memory structures to store program and data information.
  • processor circuitry may refer to one or more application processors, one or more baseband processors, a physical central processing unit (CPU), a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, and/or any other device capable of executing or otherwise operating computerexecutable instructions, such as program code, software modules, and/or functional processes.
  • Processing circuitry may include more hardware accelerators, which may be microprocessors, programmable processing devices, or the like.
  • the one or more hardware accelerators may include, for example, computer vision (CV) and/or deep learning (DL) accelerators.
  • CV computer vision
  • DL deep learning
  • application circuitry and/or “baseband circuitry” may be considered synonymous to, and may be referred to as, “processor circuitry.”
  • interface circuitry refers to, is part of, or includes circuitry that enables the exchange of information between two or more components or devices.
  • interface circuitry may refer to one or more hardware interfaces, for example, buses, I/O interfaces, peripheral component interfaces, network interface cards, and/or the like.
  • user equipment refers to a device with radio communication capabilities and may describe a remote user of network resources in a communications network.
  • the term “user equipment” or “UE” may be considered synonymous to, and may be referred to as, client, mobile, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, reconfigurable mobile device, etc.
  • the term “user equipment” or “UE” may include any type of wireless/wired device or any computing device including a wireless communications interface.
  • network element refers to physical or virtualized equipment and/or infrastructure used to provide wired or wireless communication network services.
  • network element may be considered synonymous to and/or referred to as a networked computer, networking hardware, network equipment, network node, router, switch, hub, bridge, radio network controller, RAN device, RAN node, gateway, server, virtualized VNF, NFVI, and/or the like.
  • computer system refers to any type interconnected electronic devices, computer devices, or components thereof. Additionally, the term “computer system” and/or “system” may refer to various components of a computer that are communicatively coupled with one another. Furthermore, the term “computer system” and/or “system” may refer to multiple computer devices and/or multiple computing systems that are communicatively coupled with one another and configured to share computing and/or networking resources.
  • appliance refers to a computer device or computer system with program code (e.g., software or firmware) that is specifically designed to provide a specific computing resource.
  • program code e.g., software or firmware
  • a “virtual appliance” is a virtual machine image to be implemented by a hypervisor-equipped device that virtualizes or emulates a computer appliance or otherwise is dedicated to provide a specific computing resource.
  • resource refers to a physical or virtual device, a physical or virtual component within a computing environment, and/or a physical or virtual component within a particular device, such as computer devices, mechanical devices, memory space, processor/CPU time, processor/CPU usage, processor and accelerator loads, hardware time or usage, electrical power, input/output operations, ports or network sockets, channel/link allocation, throughput, memory usage, storage, network, database and applications, workload units, and/or the like.
  • a “hardware resource” may refer to compute, storage, and/or network resources provided by physical hardware element(s).
  • a “virtualized resource” may refer to compute, storage, and/or network resources provided by virtualization infrastructure to an application, device, system, etc.
  • network resource or “communication resource” may refer to resources that are accessible by computer devices/ systems via a communications network.
  • system resources may refer to any kind of shared entities to provide services, and may include computing and/or network resources. System resources may be considered as a set of coherent functions, network data objects or services, accessible through a server where such system resources reside on a single host or multiple hosts and are clearly identifiable.
  • channel refers to any transmission medium, either tangible or intangible, which is used to communicate data or a data stream.
  • channel may be synonymous with and/or equivalent to “communications channel,” “data communications channel,” “transmission channel,” “data transmission channel,” “access channel,” “data access channel,” “link,” “data link,” “carrier,” “radiofrequency carrier,” and/or any other like term denoting a pathway or medium through which data is communicated.
  • link refers to a connection between two devices through a RAT for the purpose of transmitting and receiving information.
  • instantiate refers to the creation of an instance.
  • An “instance” also refers to a concrete occurrence of an object, which may occur, for example, during execution of program code.
  • Coupled may mean two or more elements are in direct physical or electrical contact with one another, may mean that two or more elements indirectly contact each other but still cooperate or interact with each other, and/or may mean that one or more other elements are coupled or connected between the elements that are said to be coupled with each other.
  • directly coupled may mean that two or more elements are in direct contact with one another.
  • communicatively coupled may mean that two or more elements may be in contact with one another by a means of communication including through a wire or other interconnect connection, through a wireless communication channel or link, and/or the like.
  • information element refers to a structural element containing one or more fields.
  • field refers to individual contents of an information element, or a data element that contains content.
  • SMTC refers to an SSB-based measurement timing configuration configured by SSB-MeasurementTimingConfiguration .
  • SSB refers to an SS/PBCH block.
  • a “Primary Cell” refers to the MCG cell, operating on the primary frequency, in which the UE either performs the initial connection establishment procedure or initiates the connection re-establishment procedure.
  • Primary SCG Cell refers to the SCG cell in which the UE performs random access when performing the Reconfiguration with Sync procedure for DC operation.
  • Secondary Cell refers to a cell providing additional radio resources on top of a Special Cell for a UE configured with CA.
  • Secondary Cell Group refers to the subset of serving cells comprising the
  • PSCell and zero or more secondary cells for a UE configured with DC.
  • the term “Serving Cell” refers to the primary cell for a UE in RRC CONNECTED not configured with CA/DC there is only one serving cell comprising of the primary cell.
  • serving cell refers to the set of cells comprising the Special Cell(s) and all secondary cells for a UE in RRC CONNECTED configured with CA/.
  • Special Cell refers to the PCell of the MCG or the PSCell of the SCG for DC operation; otherwise, the term “Special Cell” refers to the Pcell.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Various embodiments herein provide techniques related to identity maangement in a third generation partnership project (3GPP) fifth generation (5G) network. Some embodiments may relate to a user identity of an associated entity of a trusted user equipment (UE) or evolved residential gateway (eRG). Some embodiments may relate to eRG capabilities for supporting service access to a non-3GPP device or a premises radio access station (PRAS). Other embodiments may be described and/or claimed.

Description

FEDERATED IDENTITY MANAGEMENT IN FIFTH GENERATION (5G) SYSTEMS
CROSS REFERENCE TO RELATED APPLICATION
The present application claims priority to U.S. Provisional Patent Application No. 63/141,386, which was filed January 25, 2021 and U.S. Provisional Patent Application No. 63/151,587, filed February 19, 2021, and U.S. Provisional Patent Application No. 63/181,886, filed April 29, 2021.
FIELD
Various embodiments generally may relate to the field of wireless communications. For example, some embodiments may relate to federated identity management in fifth generation (5G) systems.
BACKGROUND
Various embodiments generally may relate to the field of wireless communications.
BRIEF DESCRIPTION OF THE DRAWINGS
Embodiments will be readily understood by the following detailed description in conjunction with the accompanying drawings. To facilitate this description, like reference numerals designate like structural elements. Embodiments are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings.
Figure 1 A depicts an illustrative diagram of a residential network, in accordance with various embodiments.
Figure IB depicts an illustrative diagram of a personal internet of things (loT) network (PIN), in accordance with various embodiments.
Figure 2 depicts an example diagram of federated identity management in a fifth generation (5G) network, in accordance with various embodiments.
Figure 3 illustrates example Nnef_ParameterProvision_Create / Nnef_ ParameterProvision Update / Nnef ParameterProvision Delete request/response operations, in accordance with various embodiments.
Figure 4 schematically illustrates example service specific information provisioning, in accordance with various embodiments.
Figure 5 illustrates an example user equipment (UE) Configuration Update procedure for transparent UE Policy delivery, in accordance with various embodiments.
Figure 6 illustrates an example non-roaming reference architecture of policy and charging control framework for the 5G System (service based representation), in accordance with various embodiments.
Figure 7 illustrates an example non-roaming reference architecture of policy and charging control framework for the 5G System (reference point representation), in accordance with various embodiments.
Figure 8 illustrates an example relationship between user, identities, identifiers and attributes, in accordance with various embodiments.
Figure 9 illustrates an example UE Configuration Update procedure for access and mobility management related parameters, in accordance with various embodiments.
Figure 10 illustrates an example UE Configuration Update procedure for transparent UE Policy delivery, in accordance with various embodiments.
Figure 11 illustrates example service-specific information provisioning, in accordance with various embodiments.
Figures 12A-C illustrate an example registration procedure, in accordance with various embodiments.
Figure 13 illustrates an example protocol data unit (PDU) Session Establishment authentication/authorization by a 5G direct network authentication, authorization, and accounting (DN-AAA) server, in accordance with various embodiments.
Figures 14A-B illustrate an example UE -requested PDU Session Establishment for nonroaming and roaming with local breakout, in accordance with various embodiments.
Figure 15 illustrates an example technique related to identity management in fifth generation systems, in accordance with various embodiments.
Figure 16 illustrates an alternative example technique related to identity management in fifth generation systems, in accordance with various embodiments.
Figure 17 schematically illustrates a wireless network in accordance with various embodiments.
Figure 18 schematically illustrates components of a wireless network in accordance with various embodiments.
Figure 19 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein.
DETAILED DESCRIPTION
The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular structures, architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the various aspects of various embodiments. However, it will be apparent to those skilled in the art having the benefit of the present disclosure that the various aspects of the various embodiments may be practiced in other examples that depart from these specific details. In certain instances, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the various embodiments with unnecessary detail. For the purposes of the present document, the phrases “A or B” and “A/B” mean (A), (B), or (A and B).
Embodiments herein relate to solutions and service requirements for the following three study items:
Third generation partnership project (3 GPP) Release- 18 (Rel-18) technical specification group service and system aspects (TSG SA) working group 1 (WG1) (collectively, “SAI”) study item [SP-200592], related to PIN.
3GPP Rel-18 SAI study item [SP-200576], related to enhancements of residential 5G network.
3GPP Release-16 (Rel-16) SAI study item description (SID)/work item description (WID) on user centric identifiers and authentication, as indicated in 3 GPP technical report (TR) 22.904 and/or 3GPP technical specification (TS) 22.101 clause 26a.
In 3GPP Rel-18 SAI, study item [SP-200592], related to PIN, has been initiated to enhance 5G-system (5GS) support of PINs, including when the PIN network is connected to the 5G-core (5GC), either using indirect network communications or other macro network connectivity (e.g. local radio access network (RAN) entities/gateways). The PIN network is a set of Personal loT devices configured to communicate between themselves and with a user equipment (UE) (e.g. smartphone, residential gateway etc) using direct device connections. Objectives of this study may include enabling 5GS support of Personal loT networks with one or more of the following aspects:
Interactions between devices in a Personal loT network and devices in the cellular network.
Interactions between devices in a Personal loT network.
Onboarding devices with operator managed credentials within the Personal loT Network from a user/UE (e.g., smartphone) or via a 5G network (e.g. a public land mobile network (PLMN)).
In addition, a Rel-18 study item [SP-200576], related to enhancements of residential 5G networks, has been initiated and one of the objectives of that study item may be to support enhancements for indoor small base stations such as: Evaluation of legacy concepts to identify how to improve the use of indoor small base stations in 5G residential use cases.
Determine the applicability of indoor small base stations in 5G residential use cases of concepts like private slices, a standalone non-public network (SNPN), a closed access group (CAG), etc. as specified for non-public networks, wherein the indoor small base station has been replaced with a new defined term at 3GPP TR 22.858 as Premises Radio Access Station (PRAS).
As an increasing number of non-3GPP devices are deployed, e.g. media server, printer, a non-access stratum (NAS) server, etc., that may provide services in a PIN or residential network for users using UEs that are either in the PIN/Residential Network or out of PIN/Residential Network. These non-3GPP devices may usually be configured behind a wireless gateway, but there may some security risks found in such settings due to port forwarding (e.g., with universal plug and play (UPnP) enabled) and unsecure connectivity provided by the wireless gateway for these non-3GPP devices at PIN/Residential network. In such a PIN/Residential network setting, an evolved residential gateway (eRG) or gateway UE with 5G capability may be used for providing 5G network connectivity to the connected non-3GPP devices or small base stations (e.g. PRAS) behind the eRG/gateway UE. Additionally, it may be desirable for the eRG/gateway UE to ensure the services provided by the non-3GPP devices or small base stations are visible in the 5G network for the authorized users from anywhere in the world to access these authorized services.
Various embodiments herein may be related to on the 3GPP TS 22.101 clause 26a, and use cases in the Rel-16 study on user-centric identifiers and authentication, as indicated in TR22.904. Such use cases may be when the operator acts as identity provider for users using 3GPP devices, in which the user can be individual human user, using a UE with a certain subscription, or an application running on or connecting via a UE or a device (“thing”) behind a gateway UE. Identifying distinguished user identities of the user (provided by some external party or by the operator) in the operator network may enable an operator to provide an enhanced user experience and optimized performance as well as to offer services to devices that are not part of a 3 GPP network. The network settings can be adapted, and services offered to users according to their needs, independent of the subscription that is used to establish the connection. By acting as an identity provider, the operator may be able to take additional information from the network into account to provide a higher level of security for the authentication of a user. The concept of identity federation may be similar to that used in data center deployments for improving security for users accessing authorized services and allowing flexible deployment scenarios, e.g. a company with many organizations located in different areas. An example of such as concept may be as is described in 3GPP TR 22.858 as follows:
Identity Provider: An Identity Provider (IdP) is an entity that creates and manages identities of users and authenticates user to other applications that rely on the IdP. IdPs are responsible for asserting digital identities with claims for the rlying applications to consume.
Service Provider: A Service Provider (SP) is an entity that provides Web Services. SPs may not authenticate users by themselves but rely on IdPs for user authentication.
Identity Federation is the process of delegating an individual’s or entity’s authentication responsibility to a trusted external party. Each partner in federation plays the role of either an IdP or a SP. In identity federation, an IdP vouches fo rthe identity of the users, and an SP provides service to the users. When a user wants to access a service of an SP, the SP delegates the authentication to the IdP. This is called federation. For identity federation to take place, the SP must trust the authentication ability of the IdP. The trusted identity providers can be on-premise federation services, corporate directories, social identity providers like Google®, Facebook®, Twitter®, etc.
In the context of an operator that acts as identity provider, embodiments herein relate to a framework to enable support of federated identity management (FIM) in the operator’s 5G network for different data network domains in the clouds, PIN, and residential network connected with the 5G network. By regarding a PIN or a residential network connected with a 5G network as data network domains, the operator acting as an identity provider may enhance the security of the PIN or residential network connected with 5G network by user authentication, service authorization, and/or access control. However, existing 5G networks may not be built to permit Federated identity management for different types of data network domains, e.g. in the cloud, PIN, or residential, which may require authentication on individual domains such that domain Y cannot access services in domain X.
Embodiments of this disclosure may relate to one or more of the following solutions: Solution 1 : Operator as identifier provider for federated identity management Solution 2: User identity of associated entity of a trusted UE/eRG
Solution 3 : Primary authentication for associated entity of a trusted UE/eRG
Solution 4: 5GS with FIM for supporting secondary authentication/authorization/access control Solutions: eRG capabilities for supporting service access to non-3GPP device or PRAS
Solution6: Authorized UE configuration for the available service domains of PINs.
Solution?: Service flows and service requirements
Legacy techniques may include secondary authentication/authorization for UEs to access services of the data network domain in the cloud. However, there may be a lack of solutions to allow an operator to act as identity provider for authenticating the associated entity of the UE/eRG in different data network domains of PIN/residential network. Additionally, legacy solutions of secondary authentication/authorization may not be able to differentiate the associated users using the UE.
By contrast, by using federated identity management in 5G networks, the solutions of user authentication/authorization/access control can be applied to different data network domains of cloud services, services provided personal loT network, and/or residential network.
Generally, this disclosure may refer to the following definitions and abbreviations in discussion of embodiments herein:
Evolved Residential Gateway (eRG): a gateway between the public operator network (fixed/mobile/cable) and a customer premises network within a residence, office or shop.
Premises Radio Access Station (PRAS): a base station installed at a customer premises network primarily for use within a residence, office, or shop. loT device: a type of UE that is dedicated for a set of specific use cases or services, and which is allowed to make use of certain features restricted to this type of UEs. In some use cases or embodiments, an loT device may be optimized for the specific needs of services and application being executed (e.g. smart home/city, smart utilities, e-Health and smart wearables). Some loT devices may not intended for human type communications.
Personal loT Network (PIN): one or more PIN Elements that communicate with each other.
PIN Element: the basic component making up a PIN-User’s Personal loT Network. The PIN Element maybe an loT device, terminal equipment (TE), mobile termination (MT), mobile equipment (ME), a “thing” as may be described in sub clause 26a.1 of 3GPP TS 22.101, or a UE.
PIN Element with Gateway Capability: a system or device that may act as a gateway that provides access to and from the public operator’s network (fixed/mobile/cable) and a PIN.
PIN Element with Management Capability: A PIN Element with PIN management Capability that has capability to manage the PIN. PIN direct connection: the connection between two PIN elements without any 3 GPP RAN or core network entities positioned between the two PIN elements. In some use cases or embodiments, a PIN direct connection may internally be relayed amongst other PIN elements or other entities (such as a wireless local area network (WLAN) access point).
Direct device connection: the connection between two UEs without a network entity in the middle.
Direct network connection: One mode of network connection, where there is no relay UE between a UE and the 5G network.
Indirect network connection: one mode of network connection, where there is a relay UE between a UE and the 5G network.
In discussions of embodiments herein, one or more of the following assumptions may be applied:
A “thing” may be associated entity of the UE/eRG including human users, a non-3GPP device (not a UE), applications running on the UE/eRG or connected to the UE/eRG, etc. The network in a residential environment may be called a Customer Premise network (CPN), in which the network provider provides 5G connectivity service via a CPN to its customer in the residential environment.
There may be more than one PIN(s) or PRAS(s) in the residential environment (aka CPN). The 5G system may be deployed as a PLMN or a SNPN by a network operator such as a Mobile Network Operator or a Non-public network operator. Embodiments herein are not limited to the type of network. While embodiments may be described with respect to a PLMN, embodiments may apply to a SNPN or another type of network.
Figures la-lb show the illustrative diagrams for the residential network and PIN, respectively.
Figure la: the eRG connected to the 5G network may provide connectivity for a PRAS or a non-3GPP device using a fixed/cable/wireless connection. The PRAS may further provide connections for UEs.
Figure lb: the PIN Element with Gateway and management Capability connected to the 5G network may provide connectivity to a PIN Element which may be a UE or non-3GPP device.
3GPP TS 22.261 clause 26a may address the use case of an operator acting as identity provider for identifying associated entity of a 3GPP UE by a user identity. The user identity may associate to one or more user profiles in which each profile is identified by a user identifier, and respective user profiles contain attributes that characterize the respective users. In this use case, a “user” may be a logical concept for an associated entity of a 3 GPP UE. Examples may include human users, non-3GPP devices, applications, etc.
When the operator network authenticates a UE, a trust-relationship may be established between the UE and operator network. An associated entity (user) to the UE may be a human user that uses the UE, a non-3GPP device connected with the UE, and/or an application/ service running on the UE or connected with the UE, in which the associated entity (user) may be identified by a user identity provided by the operator based on the information configured by the UE subscriber.
Solution 1: Operator as identifier provider for federated identity management
Embodiments herein relate to federated identity management in a 5G system as shown in Figure 2. Specifically, Figure 2 depicts an example diagram of federated identity management in a fifth generation (5G) network, in accordance with various embodiments. In these embodiments:
An operator may act as an IdP responsible for user authentication of services provided in different data network domains: o For Data network domain#! in the cloud: the operator may have a trust relationship with service provider 1 (SP1) and service provider 2 (SP2). o For Data network domain#2 in the cloud: the operator may have a trust relationship with the domain owner, which acts as an identity provider (denoted as IdP2) within the domain#2 and has a trust relationship with service provider 3 (SP3) and service provider 4 (SP4). o For Data network domain#3 in residential network:
■ The eRG may act as a gateway to interconnect two networks and relay the traffic between a residential network and the 5G network. On the one end, the eRG with 3 GPP capabilities may have trust relationship with 5G network. On the other end, the eRG may play a role of an IdP3 to manage associated entities in the data network domain of the residential network (not shown in the figure) and the trust may be assumed when the eRG and PRAS/non-3GPP device get connected using 3GPP or non-3GPP based standards.
■ The associated entity of the eRG may include a PRAS and a non- 3GPP device (e.g. media server, smart TV, game console, thermostat, smart sprinkler, etc.), which are connected with the eRG via 3 GPP or non-3GPP technologies (e.g. wifi, Bluetooth, wireline), in which each associated entity is regarded as a data network domain in the residential network and the eRG acts as a data network proxy.
■ The authenticated/authorized eRG subscriber may be able to add the information of an associated entity of the eRG to the 5G network, in which the associated entity is regarded as a user with a user identity associated to the eRG subscription. When the operator authenticates the user identity of the associated non-3GPP device(s) or PRAS(s) of the eRG, the trust may be further established between the non-3GPP device/PRAS and eRG.
■ The next level of trust may be further established between the non- 3 GPP device/PRAS and their associated entities, e.g. UEs connected to the PRAS, or the applications running on the non- 3GPP device or connected to it, as long as the operator is able to continue to authenticate the identity of these associated entities (at the second level) of trusted entities (at the first level).
■ In some embodiments, there may be more than one PRAS(s) in the Customer Premise network at residential environment).
■ In some embodiments, the PIN can also be in the CPN of residential environment.
■ In some embodiments, respective ones of the associated entity may be viewed as one or more data networks in data network domain#3. In Figure 2, only one data network is presented in data network domain#3 for simplicity. In this case, the subdomain of the data network may include the PRAS, PIN, non-3GPP device. Alternatively, each associated entity may represent one data network domain. The eRG routes the traffic based on the data network domain name, e.g. DNN. For example, within a 5G network subscriber’s account, the subscriber may be able to configure a human user, which may have a user identity in the 5G network as an associated entity of the UE, using authorized UEs to use services/applications with corresponding user identities provided in different data network domains connected with 5G networks via authorized 5G capable devices (UE or eRG), e.g. data network domain#!, #2, #3, and #4. As soon as the human user is authenticated, the human user using an authenticated/authorized UE can access authorized services provided by different authorized data network domains, which may improve signaling overhead, delay, and smooth user experiences without compromising the security. o For Data network domain#4 in PIN
■ The UE with 3 GPP capabilities may have a trust relationship with the 5G network.
■ The authenticated/authorized UE subscriber may be able to add the information of an associated entity of the UE to the 5G network, in which the associated entity is regarded as a user with user identity associated to the UE subscription. When the operator authenticates the user identity of the associated entities of the UE (e.g. non-3GPP devices, human users, and applications operated on the UE or connected to the UEs), the trust can be further established between associated entity (user) and the UE.
Based on the federated identity in 5G system, as shown in Figure 2, the following procedures may be performed by the 5G system for users accessing services provided by different data network domains in the similar manners:
- the primary authentication of 3 GPP devices (UE or eRG) as well as non-3GPP devices associated to the 3GPP devices (as is described in greater detail below with respect to solution 3).
- the secondary authentication/authorization for the users using the authenticated/authorized 3GPP devices (as is described in greater detail below with respect to solution 4).
Solution 2: User identity of associated entity of a trusted UE/eRG
This solution relates to techniques to create information for the associated entity with a user identity related to one or more user profiles in the 5G network. The associated entity of the UE/eRG may include one or more of: for data network domain in the clouds: the associated entity may include the cloud service users. for data network domain in the residential network, PIN: the associated entity may include human user, non-3GPP device/PRAS behind the UE/eRG, applications running on the UE/eRG or connected to UE/eRG, etc. Solution 2.1: Service for a user of a data network domain in the cloud
The service user information is provisioned based on the procedure in 3GPP TS 23.502: § 4.15.6.2, network exposure function (NEF) service operations information flow (to a network function (NF), for a UE and/or a UE group) with the following modifications as shown below:
- the AF receives and validate service user information from service providers.
- the AF request contains at least one of the following parameters sets of “Service Users of the Data Network Domain parameters for FIM”: o DNN (data network name) o Subdomain name associated to DNN o S-NSSAI (network slice of the PDU session) o User Identity for the associated entity of the UE as service users in data network domain o One or more user profiles of the associated entity, in which the User Profile may include one or more pieces of the following information:
■ User identifier that identified the user profile,
■ List of authorized UEs (identified by their subscription and device identifiers) for the service/application,
■ capabilities the used UEs support for authentication,
■ information regarding authentication/authorization policies required by different services and slices to authenticate a user for access to these services or slices.
■ specific service settings and parameters of the associated entity with User Identity including network parameters (e.g. QoS parameters), IMS service (e.g. MMTEL supplementary services) and operator deployed service chain settings, specific network resources (e.g., network slice).
It will be noted that the DNN (data network name), Subdomain name associated to DNN, and single network slice selection assistance information (S-NSSAI), which may be the network slice of the PDU session, may be used together to identify a data network service in the cloud.
Figure 3 illustrates example Nnef_ParameterProvision_Create / Nnef_ ParameterProvision Update / Nnef ParameterProvision Delete request/response operations, in accordance with various embodiments. The detailed message flow of Figure 3 may be as follows:
Step 0. NF subscribes to UDM notifications of UE and/or Group Subscription data updates. o the AF receives and validate service user information from service providers in a specific data network domain.
Step 1 : The AF provides one or more parameter(s) to be created or updated in a Nnef ParameterProvision Create or Nnef ParameterProvision Update or Nnef ParameterProvision Delete Request to the NEF. o The GPSI identifies the UE of the associated entity and the Transaction Reference ID identifies the transaction request between NEF and AF.
For the case of Nnef ParameterProvision Create, the NEF assigns a Transaction Reference ID to the Nnef ParameterProvision Create request. NEF checks whether the requestor is allowed to perform the requested service operation by checking requestor's identifier (e.g. AF ID).
The payload of the AF request for Nnef ParameterProvision Update Request message includes one or more of the following “Service Users of the Data Network Domain parameters for FIM”: o DNN (data network name) o User Identity of the associated entity with the UE, which is regarded as service users in data network domain o One or more user profiles of the associated entity, in which the User Profile may include one or more pieces of the following information:
User identifier that identified the user profile,
List of allowed used UEs (identified by their subscription and device identifiers), capabilities the used UEs support for authentication, information regarding authentication/authorization policies required by different services and slices to authenticate a user for access to these services or slices. specific service settings and parameters of the associated entity with User Identity including network parameters (e.g. QoS parameters), IMS service (e.g. MMTEL supplementary services) and operator deployed service chain settings, specific network resources (e.g., network slice).
Step 2: If the AF is authorized by the NEF to provision the parameters, the NEF requests to create, update and store, or delete the provisioned parameters as part of the subscriber data via Nudm ParameterProvision Create, Nudm ParameterProvision Update or Nudm ParameterProvision Delete Request message, the message includes the provisioned data and NEF reference ID.
If the requester is not authorised to provision data, then the NEF continues in Step 6 indicating the reason to failure in Nnef ParameterProvision Create/Update/Delete Response message. Step 7 does not apply in this case.
Step 3: UDM may read from UDR, by means of Nudr DM Query, corresponding subscription information in order to validate required data updates and authorize these changes for this subscriber or Group for the corresponding AF.
Step 4: If the AF is authorised by the UDM to provision the parameters for this subscriber, the UDM resolves the GPSI to SUPI, and requests to create, update or delete the provisioned parameters as part of the subscriber data via Nudr DM Create/Update/Delete Request message, the message includes the provisioned data.
UDR stores the provisioned data as part of the UE and/or Group subscription data and responds with Nudr_DM_Create/Update/Delete Response message.
If the requester is not authorised to provision data, then the UDM continues in Step 5 indicating the reason to failure in Nudm ParameterProvision Update Response message and Step 7 is not executed.
The UDM classifies the received parameters into access and mobility function (AMF)- Associated, session maangement function (SMF)-Associated parameters. o The associated entity of the UE as service users in data network domain is classified as SMF- Associated parameters.
The UDM may use the AF ID received from the NEF in Step 2 to relate the received parameter with a particular subscribed DNN and/or S-NSSAI. The UDM stores the SMF- Associated parameters under corresponding Session Management Subscription data type.
Each parameter or parameter set may be associated with a validity time. The validity time is stored at the UDM/UDR and in each of the NFs, to which parameters are provisioned (e.g. in AMF or SMF). Upon expiration of the validity time, each node deletes the parameters autonomously without explicit signaling.
Step 5 : UDM responds the request with Nudm ParameterProvision Create/Update/Delete Response. If the procedure failed, the cause value indicates the reason.
Step 6: NEF responds the request with Nnef ParameterProvision Create/Update/Delete Response. If the procedure failed, the cause value indicates the reason.
Step 7: [This Step may occur only after successful Step 4] UDM notifies the subscribed Network Function (e.g., SMF) of the updated UE and/or Group subscription data via Nudm_SDM_Notification Notify message. If the NF is SMF, the UDM performs Nudm SDM Notification (SUPI or Internal Group Identifier, SMF Associated parameter set, DNN/S-NSSAI, etc.) service operation.
The SMF stores the received SMF -Associated parameters and associates them with a PDU Session based on the DNN and S-NSSAI included in the message from UDM. The SMF identifies whether there are overlapping parameter set(s) in the Service Users of the Data Network Domain parameters for FIM and merges the parameter set(s), if necessary. The SMF may use the SMF- Associated parameters as follows:
The SMF may determine whether to perform secondary authentication/authorization with DN-AAA during PDU session establishment request procedure.
The UDM (in Step 3) can also update the corresponding UDR data via Nudr_DM_Create/Delete as appropriate.
Solution 2.2: Service for a user of a data network domain in the PIN/residential environment
The non-3GPP device or PRAS may be manually added and configured by the UE subscriber or eRG subscriber at operator’s network. As used herein, the term “non-3GPP” device refers to a device that does not have 3GPP network capabilities and/or is not registered to a 3GPP network. A “3GPP” device refers to a device that has 3GPP network capabilities and/or is registered to a 3 GPP network.
- For example, for data network domain #3 for residential network as depicted above with respect to Figure 2, such that the eRG’s subscriber may interact with the 5G network for adding these associated entities, including PRAS(s), and non-3GPP device(s) as trusted entities.
- For example, for data network domain #4 for PIN as depicted above with respect to Figure 2, such that the UE’s subscriber may interact with the 5G network for adding these associated entities, including human users, apps, and PIN device as a trusted entity.
With the configuration of the associated entity, the operator network creates the user identity for the associated entity, e.g. non-3GPP device or PRAS, of the UE/eRG subscription. Each user identity may further include one or more user profiles, each identified by a user identifier, containing corresponding attributes.
For example, for PRAS, one or more user profiles may be further created for different network slices with corresponding attributes, e.g., frequency bands, service/slice type, allowed application, etc. Additionally, the operator may also add some attributes based on operator policies for PRAS. The configuration of the user profile that includes a user identifier and corresponding attributes may be used for the service authorization and access control.
In addition, to automate the associated entity creation process, the following procedure is proposed for associating a new entity of a UE/eRG subscriber:
Optionl: A northbound API between an Application function and the 5G network may be used to automate the process for adding an associated entity (non-3GPP device or PRAS) of the UE/eRG subscriber as follows:
- When the UE or eRG receives the upper layer request, e.g. a human user scans the QR code of the new associate entity (PRAS, PIN device) which connects to the UE or eRG, to add the new associated entity with the UE subscriber or eRG subscriber, the UE or eRG connects to the application server of the associated entity, e.g. based on the QR code.
The application server of the associated entity (non-3GPP/PRAS) using AF API of AF to send AF request (using northbound API) to the 5G network for creating associated entity as a user based on the UE subscription.
Embodiments may use the procedure for service specific parameter provisioning as an example such that the AF using Nnef ServiceParameter service or a new AF request message to request creating an associated entity as a user and providing service specific parameters to the PLMN and the UE, as in 3GPP TS 23.502 Figure 4.15.6.7-1. Figure 4 depicts an example of such a technique from 3GPP TS 23.502, Figure 4.15.6.7-1. Specifically, Figure 4 Figure 4 schematically illustrates example service specific information provisioning, in accordance with various embodiments. In some embodiments, the process flow of Figure 4 may include the following modification:
Step 1 (Creation of the AF Request) may be modified such that the AF request sent to the NEF may include at least one of the following information as below:
1) User Description: User Description is the information to identify an associated entity the User information are applied to. The User Description in the AF request can contain at least one of the following information:
- user type: specify the type of the associated entity including human user, non-3GPP device, PRAS
- User ID allocated by the 5G network or application user Identity configured by the application service provider. If application user Identity is provided by the application service provider, the UDR configures a User ID in the response message. one or more user profiles for this associated entity containing corresponding user identifiers and attributes: o User identifier that identified the user profile, o List of authorized UEs (identified by their subscription and device identifiers) for the service/application, o capabilities the used UEs support for authentication, o information regarding authentication/authorization policies required by different services and slices to authenticate a user for access to these services or slices. o specific 5G network service settings and parameters of the associated entity with User ID including 5G network parameters (e.g. QoS parameters), IMS service (e.g. MMTEL supplementary services) and operator deployed service chain settings, specific network resources (e.g., network slice). o Data network parameters of the associated entity include information of local IP address domain configured by the UE/eRG. With this inforamtion, the 5G network, e.g. PCF, allocates at least one of the following information for identifying the data network domain of the associated entity: the DNN, subdomain name, and S-NSSAI. All these data network parameters can be used together to identify a data network service in the PIN/residential environment (CPN).
- Because the associated entity (non-3GPP device or PRAS) is connected and associated to the UE or eRG, which is regarded as a trusted 3GPP device, the associated entity may be dependent on the UE/eRG subscription. The UE subscription may include the Federated Identity Management services for user centric management and authentication provided by the operator.
2) Service Description: Service Description is the information to identify a service the Service Parameters are applied to. The Service Description in the AF request can be represented by the combination of DNN and S-NSSAI, an AF-Service-Identifier or an application identifier.
3) Service Parameters: Service Parameters are the service specific information which needs to be provisioned in the Network and delivered to the UE in order to support the service identified by the Service Description.
4) Target UE(s) or a group of UEs: indicate the UE(s) who the Service Parameters shall be delivered to. Individual UEs can be identified by GPSI, or an IP address/Prefix or a MAC address. Based on UE/eRG subscription and AF provisioned service specific parameter, the PCF may perform one or more of the following: creating the one or more user profiles of the associated entity. allocating at least one of the following information for identifying the data network domain of the associated entity: the DNN, subdomain name, and S-NSSAI. All these data network parameters can be used together to identify a data network service in the PIN/residential environment (CPN). configuring user policy containing information of user identifiers, data network configuration (e.g. DNN, subdomain name, and S-NSSAI), operator’s access control setting for Unified Access Control (used by the eRG to access 5G network for the associated entity), etc. as part of the UE/eRG policy for the associated entity (non- 3GPP device, PRAS). performing UE policy delivery as specified in TS23.502 clause 4.2.4.3 (e.g., step 6 of Figure 4)
Option!: A NAS procedure may be used to automate the process for adding an associated entity (e.g., a non-3GPP device or a PRAS) of the UE/eRG subscriber as follows:
- When the UE or eRG receives the upper layer request, e.g. a user scan the QR code of the new associate entity (PRAS, PIN device), to add the new associated entity with the UE subscriber or eRG subscriber, the UE or eRG initiates a registration request procedure by indicating the following information in NAS message: o A new registration type indicates the associated entity registration o A new IE includes the associated entity type, including human users, non- 3 GPP device, PRAS. o A new IE includes the User ID or user defined user Identity of the associated entity
■ The User ID can be allocated by the 5G network and user defined user Identity is configured by the associated entity/eRG/UE. If user defined user Identity is provided, the PCF/UDR configures and includes a User ID in the response message. o A new IE includes the container of the user profile of the associated entity, e g-
■ one or more user profiles for this associated entity containing corresponding user identifiers and attributes: ■ User identifier that identified the user profile,
■ List of authorized UEs (identified by their subscription and device identifiers) for the service/application,
■ capabilities the used UEs support for authentication,
■ information regarding authentication/authorization policies required by different services and slices to authenticate a user for access to these services or slices.
■ specific service settings and parameters of the associated entity with User Identity including network parameters (e.g. QoS parameters), IMS service (e.g. MMTEL supplementary services) and operator deployed service chain settings, specific network resources (e.g., network slice).
- When the AMF receives the NAS message, it requests the associated PCF of the UE/eRG to create a user profile of the associated entity at UDR. A User ID of the associated entity is created by PCF/UDR if a user defined user identity is provided in the registration request message.
In the registration accept message, the AMF includes the following information for the new added associated entity:
■ User ID of the associated entity if not provided in the registration request message.
■ User Identity type indication: human user, PIN device, PRAS, applications;
■ One or more user profiles of the associated entity with operator’s configuration.
■ allocated DNN for the data network domain, e.g. PIN or residential. The PCF may decide to update UE policy of the UE/eRG subscriber using the following procedure in 3GPP TS23.502, Figure 4.2.4.3-1 (depicted at Figure 5) with the following new information in the UE/eRG policy for the associated entity:
■ User ID of the associated entity;
■ User Identity type indication: human user, PIN device, PRAS, applications;
■ One or more user profiles of the associated entity with operator’s configuration.
The UE/eRG stores the UE/eRG policy. Specifically for PRAS, the eRG can further deliver the related configuration of the one or more user profile to the PRAS over the connection between the eRG or PRAS, in which the information can be delivered using N3 protocol (eRG is regarded as associated UPF).
Solution 3: Primary authentication for associated entity of a trusted UE/eRG
Following solution 2.2, for data network domain in PIN or residential environment, the user identity of the associated entity may be created at the 5G network.
This solution (Solution 3) may further provide a solution to register an associated entity of a UE/eRG, wherein the associated entity includes the non-3GPP devices, and PRAS.
The UE/eRG has been registered with the network to get authorized to receive 5G services and has stored NAS security context. When associated entity of the non-3GPP devices or PRAS is power on and connected to the UE/eRG using non-3GPP protocols, a UE/eRG receiving a upper layer request may perform registration procedures for the associated entity, as indicated in 3GPP TS 23.502 clause 4.2.2.2, with the following modifications:
Steps 1-3 : the registration request message indicates the following: o a new registration type indicates associated entity registration o UE/eRG ID, e g. SUPI/SUCI or 5G-GUTI or PEI o User ID of the associated entity o one or more user credentials of the associated entity for the UE/eRG, including user identifier, password, public key, token, certificate, etc., where in the user identifier can be used to locate the stored user profile of the associated entity.
Step 9: based on the registration type indicated as associated entity registration, the AMF checks the UE authentication status, e.g. how long does the UE registered, the location of the UE, etc., and determines the confidence level of the UE registration status which may require to quarry NWDAF for the analytic info. o If the confidence level of the UE registration is accepted, the AMF initiates the authentication requests with AUSF for the associated entity of the UE by indicating UE/eRG ID, User ID of the associated entity, and one or more user credentials of the associated entity. The AUSF may retrieve the user profile from UDR via UDM/PCF based on the user identifier and performs authentication of the user identity based on the user credentials stored in user profiles. In the case of the PCF, the AMF provides information of associated PCF. o If the confidence level of the UE registration is not accepted, the AMF may send registration rejection message with proper rejection cause or indication of re-registration of the UE.
Solution 4: 5GS with FIM for supporting secondary authentication/authorization/access control
Based on the diagram of an example federated identity management context for 5GS in Figure 2, the user authentication, service authorization and access control may be performed for a different data network domains in a similar manner.
When the UE requests a PDU session establishment for accessing services of the data network domains, one or more of the following two scenarios may be applied:
- For data network domain#l/#2 in the cloud
For data network domain#3/#4 in PIN/residential network, in which the eRG is with DN-AAA capabilities and the data network domain#3/#4 are allocated with Data network name (DNN) by the 5G network. Further details of this scenario may be described below with respect to Figure 5.
In the UE requested PDU session establishment request procedure as indicated in 3GPP TS23.502, clause 4.3.2.2.1, Figure 4.3.2.2.1-1 (e.g., as shown in Figures 14A and 14B), the following modification may be used:
Step 1 : the request message in includes one of the following information: o UE ID o DNN, S-NSSAI o User ID of the associated entity o Credentials for accessing the services, e.g. user identifier, security keys, public keys, token, certificates, etc.
Step 6: PDU session authentication/authorization: o Based on the User ID of the associated entity, the SMF determines the confidence level of the UE registration status, which may require to quarry NWDAF for the analytic info. o If User ID and user identifier of the associated entity is included in the request message, the SMF checks with the PCF for the corresponding user profile and determines the policies for the secondary authentication/authorization policies. The secondary authentication/authorization policies may indicate one or more of the following: o 5G network for authentication and authorization o 5G network for authentication only o DN-AAA for authentication and authorization
Based on the secondary authentication/authorization policies, the following elements for secondary authentication/authorization procedure may be performed if the confidence level of the UE registration is accepted:
The SMF initiates the secondary authentication procedure towards DN-AAA based on 3GPP TS 23.502 clause 4.3.2.3 (e.g., as may be shown in Figure 13) with the following modification: o Step 2:
■ Casel : If the authentication/authorization policy indicates 5G for authentication/authorization or 5Gfor authentication only, the SMF request AUSF for authentication/authorization directly or via AMF by indicating authentication type set as secondary authentication/authorization or authentication only, User ID, and user credentials. The AUSF may retrieve the user profile from UDR via UDM/PCF based on the user identifier and performs authentication of the user identity based on the user credentials stored in user profiles. In the case of the PCF, the AMF provides information of associated PCF.
■ If the authentication/authorization policy indicates 5G authentication only and 5G authentication by AUSF is passed, the SMF sends Authentication/Authorization request to DN-AAA indicating DN authorization only, User ID, user identifier, and confidence level of the associated UE registration. The DN-AAA performs user authorization and replies the result to the SMF.
■ Case2: If the authentication/authorization policy indicates DN- AAA for authentication/authorization, the SMF request DN-AAA for secondary authentication/authorization as existing procedure indicated in TS23.502 clause 4.3.2.3 with the following modification: for the steps 3a-3f, for the support of FIM at 5G network, the SMF may determine to transfer of DN Request Container information received from DN-AAA towards UDR via PCF.
Solution 5: eRG capabilities for supporting service access to non-3GPP device or PRAS
To support FIM for the data network domain in PIN or residential network, the eRG/UE acting as a gateway and a 5G network may need to support the following capabilities: eRG/gatway UE with 5G capabilities supports NAT (network address translation), and Data network proxy
- the 5G network manages the updates of the IP address of eRG/gateway UE and the data network domain of the associated entities.
One or more of the following features may be used to enable support of Data network proxy and NAT in 5GS: eRG/gateway UE subscription includes: o Federated Identity services of 5G network for handling user identities, user profiles, user authentication, service authorization, access control, etc. eRG/gateway UE capabilities include: o Data network proxy o DN-AAA capabilities eRG/ gateway UE ’ s regi strati on procedure : o the eRG/gateway UE indicates its eRG/gateway UE capabilities in the registration request message o the eRG/gateway UE uses PDU session modification request procedure to update DN-AAA address information at eRG by indicating a new IE in the request message. o When a new non-3GPP device or PRAS is discovered/connected to eRG/gateway UE, the eRG/gateway UE performs registration procedure to register the non-3GPP device or PRAS with user identities, the 5G network allocates DNN information for identifying the data network domain of the associated entity for the eRG/gateway UE. eRG/gateway UE transfers traffic of multiple data network domains for PIN and residential network o The eRG/gateway UE may determine to use the same or different PDU session for transferring traffic of multiple data network domains for PIN and residential. o If different PDU sessions are used for transporting user plane data for different data network domain of associated entity, the eRG/gateway UE uses PDU session request/modification procedure to provide/update the DNN information of the data network domain for the associated entities.
■ the eRG/gateway UE indicates one or more DNN(s) of data network domain(s) for the associated entity(es) in the new IE in the PDU session request/modification request message.
■ the SMF stores the mapping information between the PDU session ID and one or more DNN(s) of the data network domains for the associated entity of the eRG/gateway UE. eRG/gateway UE acts as DN proxy o The eRG/gateway UE sends a PDU session establishment request indicating the reliable connection for DN proxy and this PDU session is used for any DN related control plane traffic, e.g. authentication request/response messages. o To ensure the connectivity of the DN proxy of the eRG/gateway UE, there are two options to update the IP address of the DN proxy in the eRG/gateway UE:
■ Optionl : the SMF stores and maintains the mapping information between eRG/gateway UE ID and eRG/gateway UE address for DN proxy. The SMF updates the IP address of the eRG/gateway UE as DN proxy whenever there are changes.
■ Option2: The eRG/gateway UE has DDNS-like client to update the change of the IP address with DDNS (dynamic data domain name server) in the 5G network. The 5G network provides DDNS configuration information, e.g. IP address of the DDNS server and credential settings, in the registration accept message, PDU session establishment accept message, or in the UE configuration update procedure. Solution 6: Authorized UE configuration for the available service domains of PINs.
For allowing an authorized UE to access the service in data network domain of PIN or residential, the authorized UE may be configured with information of the data network domains via UE configuration update procedure, as indicated in 3GPP TS 23.502, Figure 4.2.4.3-1 (which may be depicted at Figure 5 herein). Such information may be related to the UE Configuration Update procedure for transparent UE Policy delivery, which is triggered by PCF for updating the following set of information for an authorized data network domain. The information may include: Authorized DNN(s) of the data network domains, e.g. PIN, Residential network Allowed S-NSSA(s) of each authorized DNN
Authorized user identifier(s) of the application(s) with user identit(ies) of each authorized DNN
Solution 7: Service flows and service requirements
Following solution 2.2, for automating the associated entity on boarding (creation) process, the embodiments related to associating a new entity of a gateway UE/PIN Element with a Gateway Capability/eRG subscriber may be applied to non-3GPP devices as new associated entity, e.g. smart home devices (smart plug, smart watch, smart garage door, etc) and PRAS.
The related use case and service flows for on boarding non-3GPP device (PIN Element) are as follows:
Step 1 : User-X (human user) has subscribed to PIN services from MNOa.
Step 2: User-X installs a smart plug (with only Bluetooth or WLAN connectivity) and wants to add it to his PIN based on the subscription for the PIN. User-X scans a bar code of the plug which guides the smartphone/UE (as gateway UE/PIN Element with Gateway Capability) to a webpage of an application server.
Step 3: Then the application server requests 5G network via AF to on board the PIN Element, i.e. smart plug. Based on the on boarding request from the UE, including the UE ID, PIN ID (if available) and the smart plug configuration information, the 5G network creates User Identity for the PIN Element and associated it with the UE. o The PIN Element sends the on boarding request to the application server is regarded as offering the permission to add the new associated PIN Element. o When the 5G network creates a PIN with a PIN ID. The corresponding PIN configuration is stored, which may be associated to the PIN Element with Gateway Capability. o Based on the stored PIN information, if the permission of adding a new PIN Element for a PIN is needed from a second PIN Element, e.g. a UE, the 5G network sends a request message asking for the permission from the second PIN Element. With the permission, the 5G network continues this step 3. Otherwise, the 5G network rejects the process to add the PIN Element and replies rejection cause in the response message to the PIN Element requesting for on boarding the PIN Element. o The permission request is sent via NAS message or user plane traffic to the second PIN Element.
Step 4: The User Profile of the PIN Element is also created (as indicated in the previous solutions) and stored at the MNOa with configuration information provided by the PIN Element via the UE. The User Profile contains the User Identifier and the configuration of the PIN Element. o User Identifier o Specific configuration settings and parameters, e.g. active/inactive time, number of accesses, etc. o Authorized communication methods, e.g. direct network connection, direct device connection, PIN direct connection (e.g. Bluetooth, WLAN, wireline). o Authentication/authorization policy and access restriction policy to access the PIN Element or application running on the PIN Element. o Credential for 5G network Authentication o Credential information for the authorized users to connect to the PIN Element o In some embodiments, the PIN Element can have one or more User Profile (each is identified by different User Identifier). For example, for the same PIN Element, it can connect via two gateways with PIN Element Gateway Capability, e.g. UE or eRG. When the PIN Element connects to different gateways, it can apply different User Profiles associated to its User Identity. Step 5 : if PIN ID is not available, the 5G network creates a PIN ID to uniquely identify the PIN and return the allocated PIN ID to the PIN Element with Gateway Capability for the PIN in the notification message responding to the on boarding request from the AF.
Step 6: The application server sends the notification message (including PIN ID, identity of the PIN Element, and authorization of the communications between the PIN Element with Gateway Capability and the PIN Element) to the PIN Element with Gateway Capability which requested to on boarding its associated non-3GPP device. Step 7: User-X gets a notification on his UE that a new PIN Element, a plug, has been added. In the meantime, User-X can see the status of the new added smart plug via the webpage and the UE.
Step 8: the PIN Element with Gateway Capability stores the configuration (e.g. the PIN Element Identity or identifier) of the PIN Element and the PIN ID.
Step 9: when the PIN Element connects to different gateways, it can apply different User Profiles associated to its User Identity and indicates User identifier and the corresponding credentials in the registration request message.
Step 10: the 5G network authenticates the non-3GPP device/PIN Element based on User profile associated to the user identifier and the credentials indicated in the registration request message.
For on boarding a PRAS (without 3GPP subscription and credentials), the same service flows may be applied with the following modification:
The PIN ID is replaced with a PRAS ID
The configuration information of the PRAS includes the PRAS radio capabilities (WLAN, wireline or 3 GPP radio capabilities and network capabilities.
If the PRAS supports 3GPP radio capabilities, it contains applicable settings, e.g. the carrier frequencies, and IAB capability (via eRG or gNB as donor IAB).
If the PRAS supports 3 GPP network capabilities, it contains applicable settings, e.g. NAS for connecting to N3IWF.
Solution 7.1: Service requirements
In some embodiments, one or more of the following service requirements may be present in the context of Solution 7, above.
The 5G network shall be able to create and manage a PIN.
A PIN Element with Gateway Capability in a PIN shall be able to on board a PIN Element connected to it to the 5G network.
The 5G network shall support suitable APIs for the third party to provide configuration information of a PIN Element connected to a PIN Element with Gateway Capability in a PIN.
The 5G network shall be able to create an identity that can uniquely identify the PIN Element and is associated to the PIN Element with Gateway Capability.
The 5G network shall be able to authenticate PIN Elements within the PIN and manage the communication with other PIN Elements using PIN direct connection. The 5G network shall be able to configure and authorize a PIN Element with Gateway Capability with PIN Element with Management Capability which can manage and configure management and configuration data of the PIN locally.
3GPP specs reference
The following provides discussion of the application of various embodiments herein to applicable 3GPP specifications. Unless otherwise indicated, the phrasing “TSXY.ABC” may refer to the 3GPP TS XY.ABC. Similarly, “TRXY.ABC” may refer to the 3GPP TR XY.ABC.
• TS23.503
Figures 6 and 7, copied from TS 23.503, illustrate examples of the overall architecture for policy and charging framework in the 5G system in both service-based and reference point representation. Specifically, Figure 5 may correspond to 3GPP TS 23.503 Figure 5.2.1-1, and illustrate an example non-roaming reference architecture of policy and charging control framework for the 5G System (service based representation), in accordance with various embodiments. Figure 7 may correspond to 3GPP TS 23.503 Figure 5.2.1-la, and illustrate an example non-roaming reference architecture of policy and charging control framework for the 5G System (reference point representation), in accordance with various embodiments.
• TS22.904
4.2 Basic concept and relations of identity management
In the context of identity management something outside a system that needs to be identified in the system is referred to as “entity”. In 3GPP such an entity is called a user. A user is not necessarily a person, it could also be an application or a device (“thing”).
The entity is uniquely represented by an identity in the system. The identity can dependent on the role of the entity in the system (e.g. which kind of service is used for which purpose). As such, a user can have several user identities - e.g. one user identity representing the professional role of the (human) user and another one representing some aspects of her private life. There is a 1 :n relation between user and user identity.
The user to be identified could be an individual human user, using a UE with a certain subscription, or an application running on or connecting via a UE, or a device (“thing”) behind a gateway UE.
Figure 8 illustrates an example relationship between user, identities, identifiers and attributes, in accordance with various embodiments. A user identity is associated with some pieces of information, which are generally called attributes. One special form of attributes are identifiers. The relation between identity and identifier is l:n.
Each user identity may be identified in the system by one or more user identifiers. An identifier could take the form of an NAI, email address or some number [UUID], could be permanent (comparable to the IMSI), or temporary (comparable to the TMSI).
As an example wherien “User Identity” relates to an individual human user, in the internetworld a user might choose to use their company email address when registering and using services (access to web portals) that they needs for their work. For access to other sites, e.g. online shopping or login to information servers concerning some hobby, they might use other email addresses. In this example, the email addresses are the user identifiers that identify the different identities of the user for certain web services.
Other attributes could contain information about the date of birth of a user, the private address, the company name and address, job title etc. Attributes that are not identifiers may be associated with more than one identity, e.g. date of birth might be relevant in the professional as well as in the private context. One identity typically is associated with several attributes.
With having multiple user accounts the above information is distributed over multiple servers. An identity provider creates, manages and stores this information in one place, authenticates a selected user identity (e.g. verifies a claimed user identity) for a service and provides the result and necessary attributes to the service.
• TS23.502, which may relate to Solution 2, described above
4,2,4 UE Configuration Update
4,2.4.1 General
UE configuration may be updated by the network at any time using UE Configuration Update procedure. UE configuration includes:
Access and Mobility Management related parameters decided and provided by the AMF. This includes the Configured NSSAI and its mapping to the Subscribed S-NSSAIs, the Allowed NSSAI and its mapping to Subscribed S-NSSAIs, the Service Gap time and the list of Rejected NS SAIs if the UE Configuration Update procedure is triggered by the AMF after Network Slice-Specific Authentication and Authorization of S-NSSAIs. If the UE and the AMF support RACS, this may also include a PLMN-assigned UE Radio Capability ID or alternatively a PLMN-assigned UE Radio Capability ID deletion indication.
- UE Policy provided by the PCF. When AMF wants to change the UE configuration for access and mobility management related parameters the AMF initiates the procedure defined in clause 4.2.4.2. When the PCF wants to change or provide new UE Policies in the UE, the PCF initiates the procedure defined in clause 4.2.4.3.
If the UE Configuration Update procedure requires the UE to initiate a Registration procedure, the AMF indicates this to the UE explicitly.
4, 2, 4, 2 UE Configuration Update procedure for access and mobility management related
This procedure is initiated by the AMF when the AMF wants to update access and mobility management related parameters in the UE configuration. Figure 9 illustrates an example UE Configuration Update procedure for access and mobility management related parameters, in accordance with various embodiments. Specifically, Figure 9 may be similar to TS23.502, Figure 4.2.4.2-1.
Clause 4, 2, 4, 3: UE Configuration Update procedure for transparent UE Policy delivery
This procedure is initiated when the PCF wants to update UE access selection and PDU Session selection related policy information (e.g. UE policy) in the UE configuration. In the nonroaming case the V-PCF is not involved and the role of the H-PCF is performed by the PCF. For the roaming scenarios, the V-PCF interacts with the AMF and the H-PCF interacts with the V- PCF.
• TS23.502, which may relate to Solution 2
4,15.6.7 _ Service specific parameter provisioning (UE, UE Group, Any UE)
This clause describes the procedures for enabling the AF to provide service specific parameters to 5G system via NEF.
The AF may issue requests on behalf of applications not owned by the PLMN serving the UE.
NOTE 1 : In the case of architecture without CAPIF support, the AF is locally configured with the API termination points for the service. In the case of architecture with CAPIF support, the AF obtains the service API information from the CAPIF core function via the Availability of service APIs event notification or Service Discover Response as specified in TS23.222.
The AF request sent to the NEF contains the information as below:
1)- Service Description.
Service Description is the information to identify a service the Service Parameters are applied to. The Service Description in the AF request can be represented by the combination of DNN and S-NSSAI, an AF-Service-Identifier or an application identifier.
2) Service Parameters.
Service Parameters are the service specific information which needs to be provisioned in the Network and delivered to the UE in order to support the service identified by the Service Description.
3) Target UE(s) or a group of UEs. (optional)
Target UE(s) or a group of UEs indicate the UE(s) who the Service Parameters shall be delivered to.
• Individual UEs can be identified by GPSI, or an IP address/Prefix or a MAC address.
• Groups of UEs can be identified by an External Group Identifiers as defined in TS 23.682 [23],
• If identifiers of target UE(s) or a group of UEs are not provided, then the Service Parameters shall be delived to any UEs using the service identified by the Service Description.
The NEF authorizes the AF request received from the AF and stores the information in the UDR as "Application Data". The Service Parameters are delivered to the targeted UE by the PCF when the UE is reachable.
As previously noted, Figure 4 (which may be similar to TS23.502 Figure 4.15.6.7-1) shows an example procedure for service specific parameter provisioning.
The AF uses Nnef ServiceParameter service to provide the service specific parameters to the PLMN and the UE.
1. To create a new request, the AF invokes an Nnef ServiceParameter Create service operation.
To update or remove an existing request, the AF invokes an Nnef ServiceParameter Update or Nnef ServiceParameter Delete service operation together with the corresponding Transaction Reference ID which was provided to the AF in Nnef_ServiceParameter_Create response message.
The content of this service operation (AF request) includes the information described in clause 5.2.6.11.
2. The AF sends its request to the NEF. The NEF authorizes the AF request. The NEF performs the following mappings:
Map the AF-Service-Identifier into DNN and S-NSSAI combination, determined by local configuration. Map the GPSI in Target UE Identifier into SUPI, according to information received from UDM.
Map the External Group Identifier in Target UE Identifier into Internal Group Identifier, according to information received from UDM.
(in the case of Nnef ServiceParameter Create): The NEF assigns a Transaction Reference ID to the Nnef ServiceParameter Create request.
3. (in the case of Nnef ServiceParameter Create or Update): The NEF stores the AF request information in the UDR as the "Application Data" (Data Subset setting to "Service specific information") together with the assigned Transaction Reference ID.
(in the case of Nnef ServiceParameter delete): The NEF deletes the AF request information from the UDR.
4. The NEF responds to the AF. In case of Nnef ServiceParameter Create response message, the response message includes the assigned Transaction Reference ID.
If the UE is registered to the network and the PCF performs the subscription to notification to the data modified in the UDR by invoking Nudr DM Sub scribe (
AF service parameter provisioning information,
- SUPI,
Data Set setting to "Application Data",
Data Subset setting to "Service specific information") at step 0, the following elements are performed:
5. The PCF(s) receive(s) a Nudr DM Notify notification of data change from the UDR.
NOTE 2: PCF does not have to subscribe for each UE the application specific information, e.g. if PCF has already received the application specific information for a group of UE or for a DNN by a subscription of other UE. The same application specific information is delivered to every UE in a group or a DNN.
6. The PCF initiates UE Policy delivery as specified in clause 4.2.4.3.
• TS23.502
5,2.6.11 _ Nnef_ServiceParameter service
5.2.6.11.1 General
This service is for allowing external party to provision of service specific parameters which can be used for the UE in 5GS. The detailed information is described in clause 4.15.6.7.
5.2.6.11.2 Nnef ServiceParam eter_ Create operation
Service operation name: Nnef ServiceParameter Create Description: The consumer stores service specific parameters in the UDR via the NEF.
Inputs (required): Service Descriptor (e.g. the combination of DNN and S-NSSAI, an AF-Service-Identifier or an application identifier)
Inputs (optional): Service Parameters and Target UE identifiers (e.g. the address (IP or Ethernet) of the UE if available, GPSI if available, External Group Identifier if available)
Outputs (required): Transaction Reference ID, operation execution result indication.
Outputs (optional): None.
5.2.6.11.3 Nnef ServiceParameter Update operation
Service operation name: Nnef ServiceParameter Update
Description: The consumer updates service specific parameters in the UDR via the NEF.
Inputs (required): Service Descriptor (e.g. the combination of DNN and S-NSSAI, an AF- Service-Identifier or an application identifier), Transaction Reference ID.
Inputs (optional): Service Parameters and Target UE identifiers (e.g. the address (IP or Ethernet) of the UE if available, GPSI if available, External Group Identifier if available).
Outputs (required): Operation execution result indication.
Outputs (optional): None.
5.2.6.11.4 Nnef ServiceParameter Delete operation
Service operation name: Nnef ServiceParameter Delete
Description: The consumer deletes service specific parameters from the UDR via the NEF.
Inputs (required): Service Descriptor (e.g. the combination of DNN and S-NSSAI, an AF- Service-Identifier or an application identifier), Transaction Reference ID.
Inputs (optional): Target UE identifiers (e.g. the address (IP or Ethernet) of the UE if available, GPSI if available, External Group Identifier if available).
Outputs (required): Operation execution result indication.
Outputs (optional): None.
5.2.6.11.5 Nnef ServiceParam eter_ Get operation
Service operation name: Nnef ServiceParameter Get
Description: The consumer retrieves service specific parameters in the UDR via the NEF.
Inputs (required): Service Descriptor (e.g. the combination of DNN and S-NSSAI, an AF-Service-Identifier or an application identifier).
Inputs (optional): Service Parameters and Target UE identifiers (e.g. the address (IP or Ethernet) of the UE if available, GPSI if available, External Group Identifier if available).
Outputs (required): Transaction Reference ID, operation execution result indication, requested data. Outputs (optional): None.
• TS23.502, which may be related to Solution 2
TS23.502: 4,15.6.2 NEF service operations information flow (to NF, for UE and UE group)
As noted, Figure 3 illustrates example Nnef_ParameterProvision_Create / Nnef_ ParameterProvision Update / Nnef ParameterProvision Delete request/response operations, in accordance with various embodiments. Figure 3 may be similar to Figure 4.15.6.2-1 of TS23.502, and include the following elements:
0. NF subscribes to UDM notifications of UE and/or Group Subscription data updates.
NOTE 1 : The NF can subscribe to Group Subscription data from UDM in this step and be notified of Group Subscription data updates in step 7 using the Shared Data feature defined in TS 29.503 [52],
Ob. [Conditional, on using NWDAF-assisted values] The AF may subscribe to NWDAF via NEF in order to learn the UE mobility analytics and/or UE Communication analytics for a UE or group of UEs by applying the procedure specified in TS 23.288 [50] clause 6.1.1.2. The Analytics Id is set to any of the values specified in TS 23.288 [50] clause 6.7.1.
0c. [Conditional, on using NWDAF-assisted values] AF validates the received data and derives any of the Expected UE behaviour parameters defined in clause 4.15.6.3 for a UE or group of UEs.
1. The AF provides one or more parameter(s) to be created or updated in a Nnef ParameterProvision Create or Nnef ParameterProvision Update or Nnef ParameterProvision Delete Request to the NEF.
The GPSI identifies the UE and the Transaction Reference ID identifies the transaction request between NEF and AF.
For the case of Nnef ParameterProvision Create, The NEF assigns a Transaction Reference ID to the Nnef ParameterProvision Create request.
- NEF checks whether the requestor is allowed to perform the requested service operation by checking requestor's identifier (e.g. AF ID).
For a Create request associated with a 5G VN group, the External Group ID identifies the 5G VN Group.
The payload of the Nnef ParameterProvision Update Request includes one or more of the following parameters: o Expected UE Behaviour parameters (see clause 4.15.6.3), or o Network Configuration parameters (see clause 4.15.6.3a), or o External Group Id and 5G VN group data (e.g. 5G-VN configuration parameters) (see clause 4.15.6.3b), or o 5G VN group membership management parameters (see clause 4.15.6.3c) o Location Privacy Indication parameters of the "LCS privacy" Data Subset of the Subscription Data (see clause 5.2.3.3.1 and TS 23.273 [51] clause 7.1)
The AF may request to delete 5G VN configuration by sending Nnef ParameterProvision Delete to the NEF.
2. If the AF is authorised by the NEF to provision the parameters, the NEF requests to create, update and store, or delete the provisioned parameters as part of the subscriber data via Nudm ParameterProvision Create, Nudm ParameterProvision Update or
Nudm ParameterProvision Delete Request message, the message includes the provisioned data and NEF reference ID.
If the requester is not authorised to provision data, then the NEF continues in step 6 indicating the reason to failure in Nnef ParameterProvision Create/Update/Delete Response message. Step 7 of this process flow does not apply in this case.
NOTE 2: For non-roaming case and no authorisation or validation by the UDM required and if the request is not associated with a 5G VN group, the NEF can directly forward the external parameter to the UDR via Nudr DM Update Request message. And in this case, the UDR responds to NEF via Nudr DM Update Response message.
3. UDM may read from UDR, by means of Nudr DM Query, corresponding subscription information in order to validate required data updates and authorize these changes for this subscriber or Group for the corresponding AF.
4. If the AF is authorised by the UDM to provision the parameters for this subscriber, the UDM resolves the GPSI to SUPI, and requests to create, update or delete the provisioned parameters as part of the subscriber data via Nudr DM Create/Update/Delete Request message, the message includes the provisioned data.
If a new 5G VN group is created, the UDM shall assign a unique Internal Group ID for the 5G VN group and include the newly assigned Internal Group ID in the Nudr DM Create Request message. In case the list of 5G VN group members is changed or in case 5G VN group parameters related with the connectivitry service of group members has changed, the UDM updates the UE and/or Group subscription data according to the AF/NEF request.
UDR stores the provisioned data as part of the UE and/or Group subscription data and responds with Nudr_DM_Create/Update/Delete Response message. When the 5G VN group data (as described in clause 4.15.6.3b) is updated, the UDR notifies to the subscribed PCF by sending Nudr_DM_Notify as defined in clause 4.16.12.2.
If the requester is not authorised to provision data, then the UDM continues in step 5 indicating the reason to failure in Nudm ParameterProvision Update Response message and step 7 is not executed.
The UDM classifies the received parameters (e.g. Expected UE Behaviour parameters or the Network Configuration parameters or the 5G VN configuration parameters or Location Privacy Indication parameters), into AMF -Associated and SMF -Associated parameters. The UDM may use the AF ID received from the NEF in step 2 to relate the received parameter with a particular subscribed DNN and/or S-NSSAI. The UDM stores the SMF- Associated parameters under corresponding Session Management Subscription data type.
Each parameter or parameter set may be associated with a validity time. The validity time is stored at the UDM/UDR and in each of the NFs, to which parameters are provisioned (e.g. in AMF or SMF). Upon expiration of the validity time, each node deletes the parameters autonomously without explicit signalling.
5. UDM responds the request with Nudm ParameterProvision Create/Update/Delete Response. If the procedure failed, the cause value indicates the reason.
6. NEF responds the request with Nnef ParameterProvision Create/Update/Delete Response. If the procedure failed, the cause value indicates the reason.
7. [Conditional this step occurs only after successful step 4] UDM notifies the subscribed Network Function (e.g., AMF) of the updated UE and/or Group subscription data via Nudm_SDM_Notification Notify message. a) If the NF is AMF, the UDM performs Nudm SDM Notification (SUPI or Internal Group Identifier, AMF-Associated parameters, etc.) service operation. The AMF identifies whether there are overlapping parameter set(s) and merges the parameter set(s) in the Expected UE Behaviour, if necessary. The AMF uses the received AMF-Associated parameters to derive the appropriate UE configuration of the NAS parameters and to derive Core Network assisted RAN parameters. The AMF may determine a Registration area based on parameters Stationary indication or Expected UE Moving Trajectory. b) If the NF is SMF, the UDM performs Nudm SDM Notification (SUPI or Internal Group Identifier, SMF- Associated parameter set, DNN/S-NSSAI, etc.) service operation.
The SMF stores the received SMF -Associated parameters and associates them with a PDU Session based on the DNN and S-NSSAI included in the message from UDM. The SMF identifies whether there are overlapping parameter set(s) in the Expected UE behaviour and merges the parameter set(s), if necessary. The SMF may use the SMF- Associated parameters as follows: SMF configures the UPF accordingly. The SMF can use the Scheduled Communication Type parameter or Suggested Number of Downlink Packets parameter to configure the UPF with how many downlink packets to buffer. The SMF may use the parameter Communication duration time to determine to deactivate UP connection and to perform CN- initiated selective deactivation of UP connection of an existing PDU Session.
The SMF may derive SMF derived CN assisted RAN information for the PDU Session. The SMF provides the SMF derived CN assisted RAN information to the AMF as described in PDU Session establishment procedure or PDU Session modification procedure.
NOTE 3: The NEF (in NOTE 1) or the UDM (in step 3) can also update the corresponding UDR data via Nudr DM Create/Delete as appropriate.
• TS23.502, which may relate to Solution 3
4,2 Connection, Registration and Mobility Management procedures
4.2.1 General
The Connection Management is used to establish and release the Control Plane signalling connection between the UE and the AMF. The Registration Management is used to register or deregister a UE/user with the 5GS, and establish the user context in the 5GS. The Mobility Management functions are used to keep track of the current location of a UE. The procedures in clause 4.2 provides Connection, Registration and Mobility Management functionality.
4.2.2 Registration Management procedures
4.2.2.1 General
The Registration and Deregistration procedures in clause 4.2.2 provides the required functionality to register or deregister a UE/user with the 5GS. Additional functionality to support Registration Management for non-3GPP access is defined in clause 4.12. Additional functionality to support Registration Management for specific services such as SMS over NAS is defined in clause 4.13.
4.2.2.2 Registration procedures
4, 2, 2, 2, 1 _ General
A UE needs to register with the network to get authorized to receive services, to enable mobility tracking and to enable reachability. The UE initiates the Registration procedure using one of the following Registration types:
Initial Registration to the 5GS;
Mobility Registration Update upon changing to a new Tracking Area (TA) outside the UE's Registration Area in both CM-CONNECTED and CM-IDLE state, or when the UE needs to update its capabilities or protocol parameters that are negotiated in Registration procedure with or without changing to a new TA, a change in the UE's Preferred Network Behaviour that would create an incompatibility with the Supported Network Behaviour provided by the serving AMF, or when the UE intends to retrieve LADN Information; or
Periodic Registration Update (due to a predefined time period of inactivity); or Emergency Registration.
The General Registration call flow in clause 4.2.2.2.2 applies on all these Registration procedures, but the periodic registration need not include all parameters that are used in other registration cases.
The following are the cleartext IES, as defined in TS24.501 that can be sent by the UE in the Registration Request message if the UE has no NAS security context:
Registration type
SUCI or 5G-GUTI or PEI
Security parameters additional GUTI
4G Tracking Area Update the indication that the UE is moving from EPS.
Aspects related to dual registration in 3GPP and non-3GPP access are described in clause 4.12. The general Registration call flow in clause 4.2.2.2.2 is also used for the case of registration in 3GPP access when the UE is already registered in a non-3GPP access, and vice versa. Registration in 3GPP access when the UE is already registered in a non-3GPP access scenario may require an AMF change, as further detailed in clause 4.12.8.
The general Registration call flow in clause 4.2.2.2.2 is also used by UEs in limited service state (see TS 23.122 [22]) registering for emergency services only (referred to as Emergency Registration), see TS 23.501 [2] clause 5.16.4.
During the initial registration the PEI is obtained from the UE. If the PEI is needed (e.g. for EIR check), the AMF shall retrieve the PEI when it establishes the NAS security context with a Security Mode Command during initial registration. The AMF operator may check the PEI with an EIR. If the PEI was retrieved by the AMF (either from the UE or another AMF), AMF shall provide it to the UDM using Nudm UECM Regi strati on in order to ensure that the UDM always has the latest PEI available e.g. for reporting event Change of SUPI-PEI association. The AMF passes the PEI to the UDM, to the SMF and the PCF. The UDM may store this data in UDR by Nudr_SDM_Update.
NOTE 1 : The use of NSI ID in the 5GC is optional and depends on the deployment choices of the operator. During the registration the Home Network can provide Steering of Roaming information to the UE via the AMF (e.g. a list of preferred PLMN/access technology combinations or HPLMN indication that 'no change of the "Operator Controlled PLMN Selector with Access Technology" list stored in the UE is needed). The Home Network can include an indication for the UE to send an acknowledgement of the reception of this information. Details regarding the handling of Steering of Roaming information including how this information is managed between the AMF and the UE are defined in TS 23.122 [22],
The AMF determines Access Type and RAT Type as defined in TS 23.501 [2] clause 5.3.2.3.
4, 2, 2, 2, 2 _ General Registration
Figures 12A, 12B, and 12C depict an example process flow related to a registration procedure, which may be similar to Figure 4.2.2.2.2-1 of TS23.502.
• TS23.502
4, 3, 2, 3 Secondary authorization/authentication by an DN-AAA server during the PDU Session establishment
The PDU Session establishment authentication/authorization is optionally triggered by the SMF during a PDU Session establishment and performed transparently via a UPF or directly with the DN-AAA server without involving the UPF if the DN-AAA server is located in the 5GC and reachable directly, as described in TS 23.501, clause 5.6.6.
In the case of Home Routed Roaming, unless specified otherwise, the SMF in the information flow defined in this clause is the H-SMF.
Figure 13 illustrates an example protocol data unit (PDU) Session Establishment authentication/authorization by a 5G direct network authentication, authorization, and accounting (DN-AAA) server, in accordance with various embodiments. Figure 13 may be similar to Figure 4.3.2.3-1 of TS23.502.
NOTE 1 : Steps 2, 3a, 3f and 4 may not be defined in the 3GPP specification. Step 3 can be repeated depending on the mechanism used.
NOTE 2: When the SMF directly communicates with the DN-AAA server without involving the UPF, Step 1 is skipped and Steps 2, 3a, 3f, 4 and 6 are executed without involving the UPF.
0. The SMF determines that it needs to contact the DN-AAA server. The SMF identifies the DN-AAA server based on local configuration or using the DN-specific identity (TS 33.501 [15]) provided by the UE inside the SM PDU DN Request Container provided by the UE in the PDU Session Establishment request or inside the EAP message in the PDU Session Authentication Complete message (TS 24.501 [25]).
NOTE 3: The content of the SM PDU DN Request Container is defined in
TS 24.501 [25],
1. If there is no existing N4 session that can be used to carry DN-related messages between the SMF and the DN, the SMF selects a UPF and triggers N4 session establishment.
2. The SMF initiates the authentication procedure with the DN-AAA via the UPF to authenticate the DN-specific identity provided by the UE as specified in TS 29.561 [63],
When available, the SMF provides the GPSI in the signalling exchanged with the DN- AAA.
The UPF transparently relays the message received from the SMF to the DN-AAA server.
3a. The DN-AAA server sends an Authentication/ Authorization message towards the SMF. The message is carried via the UPF.
3b. Transfer of DN Request Container information received from DN-AAA towards the UE.
In non-roaming and LBO cases, the SMF invokes the Namf_Communication_NlN2MessageTransfer service operation on the AMF to transfer the DN Request Container information within N1 SM information sent towards the UE.
In the case of Home Routed roaming, the H-SMF initiates a Nsmf PDUSession Update service operation to request the V-SMF to transfer DN Request Container to the UE and the V- SMF invokes the Namf_Communication_NlN2MessageTransfer service operation on the AMF to transfer the DN Request Container information within N 1 SM information sent towards the UE. In Nsmf PDUSession Update Request, the H-SMF additionally includes the H-SMF SM Context ID.
3c: The AMF sends the N1 NAS message to the UE
3d-3e. Transfer of DN Request Container information received from UE towards the DN- AAA.
When the UE responds with a N1 NAS message containing DN Request Container information, the AMF informs the SMF by invoking the Nsmf PDUSession UpdateSMContext service operation. The SMF issues an Nsmf PDUSession UpdateSMContext response.
In the case of Home Routed roaming, the V-SMF relays the N1 SM information to the H- SMF using the information of PDU Session received in step 3b via a Nsmf PDUSession Update service operation.
3f: The SMF (In HR case it is the H-SMF) sends the content of the DN Request
Container information (authentication message) to the DN-AAA server via the UPF. Step 3 may be repeated until the DN-AAA server confirms the successful authentication/authorization of the PDU Session.
4. The DN-AAA server confirms the successful authentication/authorization of the PDU Session. The DN-AAA server may provide: an SM PDU DN Response Container to the SMF to indicate successful authenti cati on/ authorizati on;
DN Authorization Data as defined in TS 23.501 clause 5.6.6; a request to get notified with the IP address(es) allocated to the PDU Session and/or with N6 traffic routing information or MAC address(es) used by the UE for the PDU Session; and an IP address (or IPV6 Prefix) for the PDU Session.
The N6 traffic routing information is defined in TS 23.501 [2] clause 5.6.7.
After the successful DN authentication/authorization, a session is kept between the SMF and the DN-AAA. If the SMF receives a DN Authorization Data, the SMF uses the DN Authorization Profile Index to apply the policy and charging control (see TS 23.501 [2] clause 5.6.6).
5. The PDU Session establishment continues and completes. In the step 7b of the Figure 4.3.2.2.1-1, if the SMF receives the DN Authorization Profile Index in DN Authorization Data from the DN-AAA, it sends the DN Authorization Profile Index to retrieve the PDU Session related policy information (described in TS 23.503 [20] clause 6.4) and the PCC rule(s) (described in TS 23.503 [20] clause 6.3) from the PCF. If the SMF receives the DN authorized Session AMBR in DN Authorization Data from the DN-AAA, it sends the DN authorized Session AMBR within the Session AMBR to the PCF to retrieve the authorized Session AMBR (described in TS 23.503 [20] clause 6.4). For PDU Session of Ethernet type, the SMF may instruct the UPF to handle VLAN information of the Ethernet frames related with the PDU Session received and sent on N6 or N19 or internal interface, as described in TS 23.501 [2] clause 5.6.10.2.
6. If requested so in step 4 or if configured so by local policies, the SMF notifies the DN-AAA with the IP/MAC address(es) and/or with N6 traffic routing information allocated to the PDU Session together with the GPSI.
Later on the SMF notifies the DN-AAA if the DN-AAA had requested to get notifications about: allocation or release of an IPV6 Prefix for the PDU Session of IP type or addition or removal of source MAC addresses for the PDU Session of Ethernet type (e.g. using IPV6 multihoming as defined in TS 23.501 [2] clause 5.6.4.3),
Change of N6 traffic routing information. When later on the PDU Session gets released as described in clause 4.3.4, the SMF notifies the DN-AAA.
The DN-AAA server may revoke the authorization for a PDU Session or update DN authorization data for a PDU Session. According to the request from DN-AAA server, the SMF may release or update the PDU Session.
At any time after the PDU Session establishment, the DN-AAA server or SMF may initiate Secondary Re-authentication procedure for the PDU Session as specified in clause 11.1.3 in TS 33.501 [15], Step 3a to step 3f are performed to transfer the Secondary Re-authentication message between the UE and the DN-AAA server. The Secondary Re-authentication procedure may start from step 3a (DN-AAA initiated Secondary Re-authentication procedure) or step 3b (SMF initiated Secondary Re-authentication procedure). For the DN-AAA server initiated Secondary Re-authentication, the message in step 3a shall include GPSI, if available, and the IP/MAC address(es) of the PDU session, for SMF to identify the corresponding UE and PDU session.
DN-AAA may initiate DN-AAA Re-authorization without performing re-authentication based on local policy. DN-AAA Re-authorization procedure may start from step 4.
During Secondary Re-authentication/Re-authorization, if the SMF receives DN Authorization Profile Index and/or DN authorized Session AMBR, the SMF reports the received value(s) to the PCF (as described in TS 23.501 [2]) by triggering the Policy Control Request Trigger as described in TS 23.503 [20],
4,3,2 PDU Session Establishment
4,3.2.1 General
A PDU Session establishment may correspond to: a UE initiated PDU Session Establishment procedure. a UE initiated PDU Session handover between 3 GPP and non-3GPP. a UE initiated PDU Session handover from EPS to 5GS. a Network triggered PDU Session Establishment procedure. In this case the network sends the device trigger message to application(s) on the UE side. The payload included in Device Trigger Request message contains information on which application on the UE side is expected to trigger the PDU Session establishment request. Based on that information, the application(s) on the UE side trigger the PDU Session Establishment procedure. For more detail refer to clause 4.13.2.
If the UE is simultaneously registered to a non-3GPP access via a N3IWF/TNGF/W-AGF located in a PLMN different from the PLMN of the 3 GPP access, the functional entities in the following procedures are located in the PLMN of the access used to exchange NAS with the UE for the PDU Session.
As specified in TS 23.501 [2], clause 5.6.1, a PDU Session may be associated either (a) with a single access type at a given time, e.g. either 3 GPP access or non-3GPP access, or (b) simultaneously with multiple access types, e.g. one 3GPP access and one non-3GPP access. A PDU Session associated with multiple access types is referred to as Multi Access-PDU (MA PDU) Session and it may be requested by ATSSS-capable UEs.
The following clause 4.3.2.2 specifies the procedures for establishing PDU Sessions associated with a single access type at a given time. The particular procedures associated with MA PDU Sessions are specified as part of the ATSSS procedures in clause 4.22.
4, 3, 2, 2 UE Requested PDU Session Establishment
4, 3, 2, 2, 1 _ Non-roaming and Roaming with Local Breakout
Clause 4.3.2.2.1 specifies PDU Session establishment in the non-roaming and roaming with local breakout cases. The procedure is used to:
Establish a new PDU Session;
Handover a PDN Connection in EPS to PDU Session in 5GS without N26 interface;
Switching an existing PDU Session between non-3GPP access and 3GPP access. The specific system behaviour in this case is further defined in clause 4.9.2; or
Request a PDU Session for Emergency services.
In the case of roaming, the AMF determines if a PDU Session is to be established in LBO or Home Routing. In the case of LBO, the procedure is as in the case of non-roaming with the difference that the AMF, the SMF, the UPF and the PCF are located in the visited network. PDU Sessions for Emergency services are never established in Home Routed mode. If Control Plane CIoT 5GS Optimisation is enabled for the PDU session with LBO, the NEF is not used as the anchor of this PDU Session.
NOTE 1 : UE provides both the S-NSSAIs of the Home PLMN and Visited PLMN to the network as described in clause 5.15.5.3 of TS 23.501 [2],
Figures 14A-B illustrate an example UE -requested PDU Session Establishment for nonroaming and roaming with local breakout, in accordance with various embodiments. Figures 14A-B may be similar to, for example, Figure 4.3.2.2.1-1. The procedure assumes that the UE has already registered on the AMF thus unless the UE is Emergency Registered the AMF has already retrieved the user subscription data from the UDM. 1. From UE to AMF : NAS Message (S-NSSAI(s), UE Requested DNN, PDU Session
ID, Request type, Old PDU Session ID, N1 SM container (PDU Session Establishment Request, [Port Management Information Container])).
In order to establish a new PDU Session, the UE generates a new PDU Session ID.
The UE initiates the UE Requested PDU Session Establishment procedure by the transmission of a NAS message containing a PDU Session Establishment Request within the N1 SM container. The PDU Session Establishment Request includes a PDU session ID, Requested PDU Session Type, a Requested SSC mode, 5GSM Capability, PCO, SM PDU DN Request Container, [Number Of Packet Filters], [Header Compression Configuration], UE Integrity Protection Maximum Data Rate, and [Always-on PDU Session Requested],
The Request Type indicates "Initial request" if the PDU Session Establishment is a request to establish a new PDU Session and indicates "Existing PDU Session" if the request refers to an existing PDU Session switching between 3GPP access and non-3GPP access or to a PDU Session handover from an existing PDN connection in EPC. If the request refers to an existing PDN connection in EPC, the S-NSSAI is set as described in TS 23.501 [2] clause 5.15.7.2
When Emergency service is required and an Emergency PDU Session is not already established, a UE shall initiate the UE Requested PDU Session Establishment procedure with a Request Type indicating "Emergency Request".
The Request Type indicates "Emergency Request" if the PDU Session Establishment is a request to establish a PDU Session for Emergency services. The Request Type indicates "Existing Emergency PDU Session" if the request refers to an existing PDU Session for Emergency services switching between 3GPP access and non-3GPP access or to a PDU Session handover from an existing PDN connection for Emergency services in EPC.
The 5GSM Core Network Capability is provided by the UE and handled by SMF as defined in TS 23.501 [2] clause 5.4.4b.
The Number Of Packet Filters indicates the number of supported packet filters for signalled QoS rules for the PDU Session that is being established. The number of packet filters indicated by the UE is valid for the lifetime of the PDU Session. For presence condition, see TS 24.501 [25],
The UE Integrity Protection Maximum Data Rate indicates the maximum data rate up to which the UE can support UP integrity protection. The UE shall provide the UE Integrity Protection Data Rate capability independently of the Access Type over which the UE sends the PDU Session Establishment Request.
If the use of header compression for Control Plane CIoT 5GS optimisation was negotiated successfully between the UE and the network in the previous registration procedure, the UE shall include the Header Compression Configuration, unless "Unstructured" PDU Session Type is indicated. The Header Compression Configuration includes the information necessary for the header compression channel setup. Optionally, the Header Compression Configuration may include additional header compression context parameters.
The NAS message sent by the UE is encapsulated by the AN in a N2 message towards the AMF that should include User location information and Access Type Information.
The PDU Session Establishment Request message may contain SM PDU DN Request Container containing information for the PDU Session authorization by the external DN.
The UE includes the S-NSSAI from the Allowed NSSAI of the current access type. If the Mapping of Allowed NSSAI was provided to the UE, the UE shall provide both the S-NSSAI of the VPLMN from the Allowed NSSAI and the corresponding S-NSSAI of the HPLMN from the Mapping Of Allowed NSSAI.
If the procedure is triggered for SSC mode 3 operation, the UE shall also include the Old PDU Session ID which indicates the PDU Session ID of the on-going PDU Session to be released, in NAS message. The Old PDU Session ID is included only in this case.
The AMF receives from the AN the NAS SM message (built in step 1) together with User Location Information (e.g. Cell Id in the case of the NG-RAN).
The UE shall not trigger a PDU Session establishment for a PDU Session corresponding to a LADN when the UE is outside the area of availability of the LADN.
If the UE is establishing a PDU session for IMS, and the UE is configured to discover the P-CSCF address during connectivity establishment, the UE shall include an indicator that it requests a P-CSCF IP address(es) within the SM container.
The PS Data Off status is included in the PCO in the PDU Session Establishment Request message.
The UE capability to support Reliable Data Service is included in the PCO in the PDU Session Establishment Request message.
If the UE has indicated that it supports transfer of Port Management Information Containers as per UE 5GSM Core Network Capability, then the UE shall include the MAC address of the DS-TT Ethernet port used for this PDU session. If the UE is aware of the UE-DS-TT Residence Time, then the UE shall additionally include the UE-DS-TT Residence Time.
If the UE requests to establish always-on PDU session, the UE includes an Always-on PDU Session Requested indication in the PDU Session Establishment Request message.
Port Management Information Container is received from DS-TT and includes port management capabilities, e.g. information indicating which standardized and deployment-specific port management information is supported by DS-TT as defined in TS 23.501 [2] clause 5.28.3. 2. The AMF determines that the message corresponds to a request for a new PDU Session based on that Request Type indicates "initial request" and that the PDU Session ID is not used for any existing PDU Session of the UE. If the NAS message does not contain an S-NSSAI, the AMF determines an S-NSSAI of the Serving PLMN for the requested PDU Session from the current Allowed NSSAI for the UE. If there is only one S-NSSAI in the Allowed NSSAI, this S- NSSAI shall be used. If there is more than one S-NSSAI in the Allowed NSSAI, the S-NSSAI selected is either according to the UE subscription, if the subscription contains only one default S-NSSAI and the corresponding mapped HPLMN S-NSSAI of the Serving PLMN is included in the Allowed NSSAI, or based on operator policy (e.g. also ensures any UE Requested DNN is allowed for the selected S-NSSAI)). When the NAS Message contains an S-NSSAI of the Serving PLMN but it does not contain a DNN, the AMF determines the DNN for the requested PDU Session by selecting the default DNN for this S-NSSAI if the default DNN is present in the UE's Subscription Information (or for the corresponding S-NSSAI of the HPLMN, in the case of LBO); otherwise the serving AMF selects a locally configured DNN for this S-NSSAI of the Serving PLMN. If the AMF cannot select an SMF (e.g. the UE requested DNN is not supported by the network, or the UE requested DNN is not in the Subscribed DNN List for the S-NSSAI (or its mapped value for the HPLMN in the case of LBO) and wildcard DNN is not included in the Subscribed DNN list), the AMF shall, based on operator policies received from PCF, either reject the NAS Message containing PDU Session Establishment Request from the UE with an appropriate cause or request PCF to replace the UE requested DNN by a selected DNN. If the DNN requested by the UE is present in the UE subscription information but indicated for replacement in the operator policies received from PCF, the AMF shall request the PCF to perform a DNN replacement to a selected DNN. AMF requests DNN replacement as as specified in clause 4.16.2.1.1. If the DNN requested by the UE is present in the UE subscription information but not supported by the network and not indicated for replacement in the operator policies received from PCF, the AMF shall reject the NAS Message containing PDU Session Establishment Request from the UE with an appropriate cause value.
The AMF selects an SMF as described in clause 6.3.2 of TS 23.501 [2] and clause 4.3.2.2.3. If the Request Type indicates "Initial request" or the request is due to handover from EPS or from non-3GPP access serving by a different AMF, the AMF stores an association of the S-NSSAI(s), the DNN, the PDU Session ID, the SMF ID as well as the Access Type of the PDU Session.
During registration procedures, the AMF determines the use of the Control Plane CIoT 5GS Optimisation or User Plane CIoT 5GS Optimisation based on UEs indications in the 5G Preferred Network Behaviour, the serving operator policies and the network support of CIoT 5GS optimisations. The AMF selects an SMF that supports Control Plane CIoT 5GS optimisation or User Plane CIoT 5GS Optimisation as described in clause 6.3.2 of TS 23.501 [2],
If the Request Type is "initial request" and if the Old PDU Session ID indicating the existing PDU Session is also contained in the message, the AMF selects an SMF as described in clause 4.3.5.2 and stores an association of the new PDU Session ID, the S-NSSAI(s), the selected SMF ID as well as Access Type of the PDU Session.
If the Request Type indicates "Existing PDU Session", the AMF selects the SMF based on SMF -ID received from UDM. The case where the Request Type indicates "Existing PDU Session", and either the AMF does not recognize the PDU Session ID or the subscription context that the AMF received from UDM during the Registration or Subscription Profile Update Notification procedure does not contain an SMF ID corresponding to the PDU Session ID constitutes an error case. The AMF updates the Access Type stored for the PDU Session.
If the Request Type indicates "Existing PDU Session" referring to an existing PDU Session moved between 3GPP access and non-3GPP access, then if the Serving PLMN S-NSSAI of the PDU Session is present in the Allowed NSSAI of the target access type, the PDU Session Establishment procedure can be performed in the following cases: the SMF ID corresponding to the PDU Session ID and the AMF belong to the same PLMN; the SMF ID corresponding to the PDU Session ID belongs to the HPLMN;
Otherwise the AMF shall reject the PDU Session Establishment Request with an appropriate reject cause.
NOTE 2: The SMF ID includes the PLMN ID that the SMF belongs to.
The AMF shall reject a request coming from an Emergency Registered UE and the Request Type indicates neither "Emergency Request" nor "Existing Emergency PDU Session". When the Request Type indicates "Emergency Request", the AMF is not expecting any S-NSSAI and DNN value provided by the UE and uses locally configured values instead. The AMF stores the Access Type of the PDU Session.
If the Request Type indicates "Emergency Request" or "Existing Emergency PDU Session", the AMF selects the SMF as described in TS 23.501 [2], clause 5.16.4.
3. From AMF to SMF : Either Nsmf PDUSession CreateSMContext Request (SUPI, selected DNN, UE requested DNN, S-NSSAI(s), PDU Session ID, AMF ID, Request Type, PCF ID, Priority Access, [Small Data Rate Control Status], N1 SM container (PDU Session Establishment Request), User location information, Access Type, RAT Type, PEI, GPSI, UE presence in LADN service area, Subscription For PDU Session Status Notification, DNN Selection Mode, Trace Requirements, Control Plane CIoT 5GS Optimisation indication, or Control Plane Only indicator) or Nsmf PDUSession UpdateSMContext Request (SUPI, DNN, S-NSSAI(s), SM Context ID, AMF ID, Request Type, N1 SM container (PDU Session Establishment Request), User location information, Access Type, RAT type, PEI, Serving Network (PLMN ID, or PLMN ID and NID, see clause 5.18 of TS 23.501 [2])).
If the AMF does not have an association with an SMF for the PDU Session ID provided by the UE (e.g. when Request Type indicates "initial request"), the AMF invokes the Nsmf PDUSession CreateSMContext Request, but if the AMF already has an association with an SMF for the PDU Session ID provided by the UE (e.g. when Request Type indicates "existing PDU Session"), the AMF invokes the Nsmf PDUSession UpdateSMContext Request.
The AMF sends the S-NSSAI of the Serving PLMN from the Allowed NSSAI to the SMF. For roaming scenario in local breakout (LBO), the AMF also sends the corresponding S-NSSAI of the HPLMN from the Mapping Of Allowed NSSAI to the SMF.
The AMF ID is the UE's GUAMI which uniquely identifies the AMF serving the UE. The AMF forwards the PDU Session ID together with the N1 SM container containing the PDU Session Establishment Request received from the UE. The GPSI shall be included if available at AMF.
The AMF determines Access Type and RAT Type, see clause 4.2.2.2.L
The AMF provides the PEI instead of the SUPI when the UE in limited service state has registered for Emergency services (e.g. Emergency Registered) without providing a SUPI. The PEI is defined in TS 23.501 [2] clause 5.9.3. If the UE in limited service state has registered for Emergency services (e.g. Emergency Registered) with a SUPI but has not been authenticated the AMF indicates that the SUPI has not been authenticated. The SMF determines that the UE has not been authenticated when it does not receive a SUPI for the UE or when the AMF indicates that the SUPI has not been authenticated.
If the AMF determines that the selected DNN corresponds to an LADN then the AMF provides the "UE presence in LADN service area" that indicates if the UE is IN or OUT of the LADN service area.
If the Old PDU Session ID is included in step 1, and if the SMF is not to be reallocated, the AMF also includes Old PDU Session ID in the Nsmf PDUSession CreateSMContext Request.
DNN Selection Mode is determined by the AMF. It indicates whether an explicitly subscribed DNN has been provided by the UE in its PDU Session Establishment Request.
The SMF may use DNN Selection Mode when deciding whether to accept or reject the UE request. When the Establishment cause received as part of AN parameters during the Registration procedure or Service Request procedure is associated with priority services (e.g. MPS, MCS), the AMF includes a Message Priority header to indicate priority information. The SMF uses the Message Priority header to determine if the UE request is subject to exemption from NAS level congestion control. Other NFs relay the priority information by including the Message Priority header in service-based interfaces, as specified in TS 29.500 [17],
In the local breakout case, if the SMF (in the VPLMN) is not able to process some part of the N1 SM information that Home Routed Roaming is required, and the SMF responds to the AMF that it is not the right SMF to handle the N1 SM message by invoking Nsmf PDUSession CreateSMContext Response service operation. The SMF includes a proper Ni l cause code triggering the AMF to proceed with home routed case. The procedure starts again at step 2 of clause 4.3.2.2.2.
The AMF may include a PCF ID in the Nsmf PDUSession CreateSMContext Request. This PCF ID identifies the H-PCF in the non-roaming case and the V-PCF in the local breakout roaming case.
The AMF includes Trace Requirements if Trace Requirements have been received in subscription data.
If the AMF decides to use the Control Plane CIoT 5GS Optimisation or User Plane CIoT 5GS Optimisation as specified in step 2 or to only use Control Plane CIoT 5GS Optimisation for the PDU session as described in clause 5.31.4 of TS 23.501 [2], the AMF sends the Control Plane CIoT 5GS Optimisation indication or Control Plane Only indicator to the SMF.
If the AMF determines that the RAT type is NB-IoT and the number of PDU Sessions with user plane resources activated for the UE has reached the maximum number of supported user plane resources (0, 1 or 2) based on whether the UE supports UP data transfer and the UE's 5GMM Core Network Capability as described in Clause 5.31.19 of TS 23.501 [2], the AMF may either reject the PDU Session Establishment Request or continue with the PDU Session establishment and include the Control Plane CIoT 5GS Optimisation indication or Control Plane Only indicator to the SMF.
The AMF includes the latest Small Data Rate Control Status if it has stored it for the PDU Session.
If the RAT type was included in the message, then the SMF stores the RAT type in SM Context.
If the UE supports CE mode B and and use of CE mode B is not restricted according to the Enhanced Coverage Restriction information in the UE context in the AMF, then the AMF shall include the extended NAS-SM timer indication. Based on the extended NAS-SM timer indication, the SMF shall use the extended NAS-SM timer setting for the UE as specified in TS 24.501 [25],
4. If Session Management Subscription data for corresponding SUPI, DNN and S- NSSAI of the HPLMN is not available, then SMF retrieves the Session Management Subscription data using Nudm_SDM_Get (SUPI, Session Management Subscription data, selected DNN, S- NSSAI of the HPLMN, Serving PLMN ID, [NID]) and subscribes to be notified when this subscription data is modified using Nudm SDM Subscribe (SUPI, Session Management Subscription data, selected DNN, S-NSSAI of the HPLMN, Serving PLMN ID, [NID]). UDM may get this information from UDR by Nudr DM Query (SUPI, Subscription Data, Session Management Subscription data, selected DNN, S-NSSAI of the HPLMN, Serving PLMN ID, [NID]) and may subscribe to notifications from UDR for the same data by Nudr DM sub scribe.
The SMF may use DNN Selection Mode when deciding whether to retrieve the Session Management Subscription data e.g. if the (selected DNN, S-NSSAI of the HPLMN) is not explicitly subscribed, the SMF may use local configuration instead of Session Management Subscription data.
If the Request Type in step 3 indicates "Existing PDU Session" or "Existing Emergency PDU Session" the SMF determines that the request is due to switching between 3GPP access and non-3GPP access or due to handover from EPS. The SMF identifies the existing PDU Session based on the PDU Session ID. In such a case, the SMF does not create a new SM context but instead updates the existing SM context and provides the representation of the updated SM context to the AMF in the response.
If the Request Type is "Initial request" and if the Old PDU Session ID is included in Nsmf PDUSession CreateSMContext Request, the SMF identifies the existing PDU Session to be released based on the Old PDU Session ID.
Subscription data includes the Allowed PDU Session Type(s), Allowed SSC mode(s), default 5QI and ARP, subscribed Session-AMBR, SMF -Associated external parameters.
Static IP address/prefix may be included in the subscription data if the UE has subscribed to it.
The SMF checks the validity of the UE request: it checks
Whether the UE request is compliant with the user subscription and with local policies;
(If the selected DNN corresponds to an LADN), whether the UE is located within the LADN service area based on the "UE presence in LADN service area" indication from the AMF. If the AMF does not provide the "UE presence in LADN service area" indication and the SMF determines that the selected DNN corresponds to a LADN, then the SMF considers that the UE is OUT of the LADN service area.
The SMF determines whether the PDU Session requires redundancy and the SMF determines the RSN as described in TS 23.501 [2] clause 5.33.2.1. If the SMF determines that redundant handling is not allowed or not possible for the given PDU Session, the SMF shall either reject the establishment of the PDU Session or accept the establishment of a PDU session without redundancy handling based on local policy.
If the UE request is considered as not valid, the SMF decides to not accept to establish the PDU Session.
NOTE 3 : The SMF can, instead of the Nudm SDM Get service operation, use the
Nudm SDM Sub scribe service operation with an Immediate Report Indication that triggers the UDM to immediately return the subscribed data if the corresponding feature is supported by both the SMF and the UDM.
5. From SMF to AMF: Either Nsmf PDUSession CreateSMContext Response (Cause, SM Context ID or N1 SM container (PDU Session Reject (Cause))) or an Nsmf PDUSession UpdateSMContext Response depending on the request received in step 3.
If the SMF received Nsmf PDUSession CreateSMContext Request in step 3 and the SMF is able to process the PDU Session establishment request, the SMF creates an SM context and responds to the AMF by providing an SM Context ID.
If the UP Security Policy for the PDU Session is determined to have Integrity Protection set to "Required", the SMF may, based on local configuration, decide whether to accept or reject the PDU Session request based on the UE Integrity Protection Maximum Data Rate.
NOTE 4: The SMF can e.g. be configured to reject a PDU Session if the UE Integrity
Protection Maximum Data Rate has a very low value, if the services provided by the DN would require higher bitrates.
When the SMF decides to not accept to establish a PDU Session, the SMF rejects the UE request via NAS SM signalling including a relevant SM rejection cause by responding to the AMF with Nsmf PDUSession CreateSMContext Response. The SMF also indicates to the AMF that the PDU Session ID is to be considered as released, the SMF proceeds to step 20 and the PDU Session Establishment procedure is stopped.
6. Optional Secondary authentication/authorization.
If the Request Type in step 3 indicates "Existing PDU Session", the SMF does not perform secondary authentication/authorization.
If the Request Type received in step 3 indicates "Emergency Request" or "Existing Emergency PDU Session", the SMF shall not perform secondary authentication\authorization. If the SMF needs to perform secondary authentication/authorization during the establishment of the PDU Session by a DN-AAA server as described in TS 23.501 [2] clause 5.6.6, the SMF triggers the PDU Session establishment authentication/authorization as described in clause 4.3.2.3.
7a. If dynamic PCC is to be used for the PDU Session, the SMF performs PCF selection as described in TS 23.501 [2], clause 6.3.7.1. If the Request Type indicates "Existing PDU Session" or "Existing Emergency PDU Session", the SMF shall use the PCF already selected for the PDU Session.
Otherwise, the SMF may apply local policy.
7b. The SMF may perform an SM Policy Association Establishment procedure as defined in clause 4.16.4 to establish an SM Policy Association with the PCF and get the default PCC Rules for the PDU Session. The GPSI shall be included if available at SMF. If the Request Type in step 3 indicates "Existing PDU Session", the SMF may provide information on the Policy Control Request Trigger condition(s) that have been met by an SMF initiated SM Policy Association Modification procedure as defined in clause 4.16.5.1. The PCF may provide policy information defined in clause 5.2.5.4 (and in TS 23.503 [20]) to SMF.
The PCF, based on the Emergency DNN, sets the ARP of the PCC rules to a value that is reserved for Emergency services as described in TS 23.503 [20],
NOTE 5: The purpose of step 7 is to receive PCC rules before selecting UPF. If PCC rules are not needed as input for UPF selection, step 7 can be performed after step 8.
8. If the Request Type in step 3 indicates "Initial request", the SMF selects an SSC mode for the PDU Session as described in TS 23.501 [2] clause 5.6.9.3. The SMF also selects one or more UPFs as needed as described in TS 23.501 [2] clause 6.3.3. In the case of PDU Session Type IPv4 or IPv6 or IPv4v6, the SMF allocates an IP address/prefix for the PDU Session (unless configured otherwise) as described in TS 23.501 [2] clause 5.8.2. In the case of PDU Session Type IPv6 or IPv4v6, the SMF also allocates an interface identifier to the UE for the UE to build its link-local address. For Unstructured PDU Session Type the SMF may allocate an IPv6 prefix for the PDU Session and N6 point-to-point tunnelling (based on UDP/IPv6) as described in TS 23.501 [2] clause 5.6.10.3. For Ethernet PDU Session Type, neither a MAC nor an IP address is allocated by the SMF to the UE for this PDU Session.
If the AMF indicated Control Plane CIoT 5GS Optimisation in step 3 for this PDU session, then,
1) For Unstructured PDU Session Type, the SMF checks whether UE's subscription include a "NEF Identity forNIDD" for the DNN/S-NSSAI combination. When the "NEF Identity for NIDD" is present in the UE's subscription data, the SMF will select the NEF identified for the S-NSSAI and selected DNN in the "NEF Identity for NIDD" as the anchor of this PDU Session. Otherwise, the SMF will select a UPF as the anchor of this PDU Session.
2) For other PDU Session Types, the SMF will perform UPF selection to select a UPF as the anchor of this PDU Session.
If the Request Type in Step 3 is "Existing PDU Session", the SMF maintains the same IP address/prefix that has already been allocated to the UE in the source network.
If the Request Type in step 3 indicates "Existing PDU Session" referring to an existing PDU Session moved between 3 GPP access and non-3GPP access the SMF maintains the SSC mode of the PDU Session, the current PDU Session Anchor and IP address.
NOTE 6: The SMF may decide to trigger e.g. new intermediate UPF insertion or allocation of a new UPF as described in step 5 in clause 4.2.3.2.
If the Request Type indicates "Emergency Request", the SMF selects the UPF as described in TS 23.501 [2] clause 5.16.4 and selects SSC mode 1.
SMF may select a UPF (e.g. based on requested DNN/S-NSSAI) that supports NW-TT functionality.
9. SMF may perform an SMF initiated SM Policy Association Modification procedure as defined in clause 4.16.5.1 to provide information on the Policy Control Request Trigger condition(s) that have been met. If Request Type is "initial request" and dynamic PCC is deployed and PDU Session Type is IPv4 or IPv6 or IPv4v6, SMF notifies the PCF (if the Policy Control Request Trigger condition is met) with the allocated UE IP address/prefix(es).
When PCF is deployed, the SMF shall further report the PS Data Off status to PCF if the PS Data Off Policy Control Request Trigger is provisioned, the additional behaviour of SMF and PCF for 3GPP PS Data Off is defined in TS 23.503 [20],
NOTE 7: If an IP address/prefix has been allocated before step 7 (e.g. subscribed static IP address/prefix in UDM/UDR) or the step 7 is perform after step 8, the IP address/prefix can be provided to PCF in step 7, and the IP address/prefix notification in this step can be skipped.
PCF may provide updated policies to the SMF. The PCF may provide policy information defined in clause 5.2.5.4 (and in TS 23.503 [20]) to SMF.
10. If Request Type indicates "initial request", the SMF initiates an N4 Session Establishment procedure with the selected UPF(s), otherwise it initiates an N4 Session Modification procedure with the selected UPF(s):
10a. The SMF sends anN4 Session Establishment/Modification Request to the UPF and provides Packet detection, enforcement and reporting rules to be installed on the UPF for this PDU Session. If the SMF is configured to request IP address allocation from UPF as described in TS 23.501 [2] clause 5.8.2 then the SMF indicates to the UPF to perform the IP address/prefix allocation, and includes the information required for the UPF to perform the allocation. If the selective User Plane deactivation is required for this PDU Session, the SMF determines the Inactivity Timer and provides it to the UPF. The SMF provides Trace Requirements to the UPF if it has received Trace Requirements. If the Reliable Data Service is enabled for the PDU Session by the SMF as specified in TS 23.501 [2], the RDS Configuration information is provided to the UPF in this step. The SMF provides Small Data Rate Control parameters to the UPF for the PDU Session, if required. The SMF provides the Small Data Rate Control Status to the UPF, if received from the AMF. If the Serving PLMN intends to enforce Serving PLMN Rate Control (see clause 5.31.14.2 of TS 23.501 [2]) for this PDU session then the SMF shall provide Serving PLMN Rate Control parameters to UPF for limiting the rate of downlink control plane data packets.
For a PDU Session of type Ethernet, SMF (e.g. for a certain requested DNN/S-NSSAI) may include an indication to request UPF to provide port numbers.
If SMF decides to perform redundant transmission for one or more QoS Flows of the PDU session as described in clause 5.33.1.2 of TS 23.501 [2], two CN Tunnel Info are requested by the SMF from the UPF. The SMF also indicates the UPF to eliminate the duplicated packet for the QoS Flow in uplink direction. The SMF indicates the UPF that one CN Tunnel Info is used as the redundancy tunnel of the PDU session described in clause 5.33.2.2 of TS 23.501 [2],
If SMF decides to insert two I-UPF s between the PSA UPF and the NG-RAN for redundant transmission as described in clause 5.33.1.2 ofTS 23.501 [2], the SMF requests the corresponding CN Tunnel Info and provides them to the I-UPFs and PSA UPF respectively. The SMF also indicates the PSA UPF to eliminate the duplicated packet for the QoS Flow in uplink direction. The SMF indicates the PSA UPF that one CN Tunnel Info is used as the redundancy tunnel of the PDU session described in clause 5.33.2.2 of TS 23.501 [2],
NOTE 8: The method to perform elimination and reordering on RAN/UPF based on the packets received from the two GTP-U tunnels is up to RAN/UPF implementation. The two GTP-U tunnels are terminated at the same RAN node and UPF.
If Control Plane CIoT 5GS Optimiation is enabled for this PDU session and the SMF selects the NEF as the anchor of this PDU Session in step 8, the SMF performs SMF-NEF Connection Establishment Procedure as described in clause 4.25.2.
10b. The UPF acknowledges by sending an N4 Session Establishment/Modification Response.
If the SMF indicates in step 10a that IP address/prefix allocation is to be performed by the UPF then this response contains the requested IP address/prefix. The requested CN Tunnel Info is provided to SMF in this step. If SMF indicated the UPF to perform packet duplication and elimination for the QoS Flow in step 10a, two CN Tunnel Info are allocated by the UPF and provided to the SMF. If SMF decides to insert two I-UPFs between the PSA UPF and the NG- RAN for redundant transmission as described in clause 5.33.1.2 of TS 23.501 [2], CN Tunnel Info of two I-UPFs and the UPF (PSA) are allocated by the UPFs and provided to the SMF. The UPF indicates the SMF that one CN Tunnel Info is used as the redundancy tunnel of the PDU session as described in clause 5.33.2.2 of TS 23.501 [2],
If SMF requested UPF to provide port numbers then UPF includes the DS-TT port and Bridge ID in the response according to TS 23.501 [2],
If multiple UPFs are selected for the PDU Session, the SMF initiate N4 Session Establishment/Modification procedure with each UPF of the PDU Session in this step.
NOTE 9: If the PCF has subscribed to the UE IP address change Policy Control
Trigger (as specified in clause 6.1.3.5 of TS 23.503 [20]) then the SMF notifies the PCF about the IP address/prefix allocated by the UPF. This is not shown in figure 4.3.2.2.1-1.
11. SMF to AMF: Namf_Communication_NlN2MessageTransfer (PDU Session ID, N2 SM information (PDU Session ID, QFI(s), QoS Profile(s), CN Tunnel Info, S-NSSAI from the Allowed NSSAI, Session-AMBR, PDU Session Type, User Plane Security Enforcement information, UE Integrity Protection Maximum Data Rate, RSN), N1 SM container (PDU Session Establishment Accept ([QoS Rule(s) and QoS Flow level QoS parameters if needed for the QoS Flow(s) associated with the QoS rule(s)], selected SSC mode, S-NSSAI(s), UE Requested DNN, allocated IPv4 address, interface identifier, Session-AMBR, selected PDU Session Type, [Reflective QoS Timer] (if available), [P-CSCF address(es)], [Control Plane Only indicator], [Header Compression Configuration], [Always-on PDU Session Granted], [Small Data Rate Control parameters], [Small Data Rate Control Status], [Serving PLMN Rate Control]))). If multiple UPFs are used for the PDU Session, the CN Tunnel Info contains tunnel information related with the UPFs that terminate N3.
The SMF may provide the SMF derived CN assisted RAN parameters tuning to the AMF by invoking Nsmf_PDUSession_SMContextStatusNotify (SMF derived CN assisted RAN parameters tuning) service. The AMF stores the SMF derived CN assisted RAN parameters tuning in the associated PDU Session context for this UE.
The N2 SM information carries information that the AMF shall forward to the (R)AN which includes:
The CN Tunnel Info corresponds to the Core Network address(es) of the N3 tunnel corresponding to the PDU Session. If two CN Tunnel Info are included for the PDU session for redundant transmission, the SMF also indicates the NG-RAN that one of the CN Tunnel Info used as the redundancy tunnel of the PDU session as described in clause 5.33.2.2 of TS 23.501 [2], One or multiple QoS profiles and the corresponding QFIs can be provided to the (R)AN. This is further described in TS 23.501 [2] clause 5.7. The SMF may indicate for each QoS Flow whether redundant transmission shall be performed by a corresponding redundant transmission indicator.
The PDU Session ID may be used by AN signalling with the UE to indicate to the UE the association between (R)AN resources and a PDU Session for the UE.
A PDU Session is associated to an S-NSSAI of the HPLMN and, if applicable, to a S-NSSAI of the VPLMN, and a DNN. The S-NSSAI provided to the (R)AN, is the S-NSSAI with the value for the Serving PLMN (e.g. the HPLMN S-NSSAI or, in LBO roaming case, the VPLMN S-NSSAI).
User Plane Security Enforcement information is determined by the SMF as described in clause 5.10.3 of TS 23.501 [2],
If the User Plane Security Enforcement information indicates that Integrity Protection is "Preferred" or "Required", the SMF also includes the UE Integrity Protection Maximum Data Rate as received in the PDU Session Establishment Request.
The use of the RSN parameter by NG-RAN is described in TS 23.501 [2] clause 5.33.2.1.
The N1 SM container contains the PDU Session Establishment Accept that the AMF shall provide to the UE. If the UE requested P-CSCF discovery then the message shall also include the P-CSCF IP address(es) as determined by the SMF and as described in TS 23.501 [2] clause 5.16.3.4. The PDU Session Establishment Accept includes S-NSSAI from the Allowed NS SAI. For LBO roaming scenario, the PDU Session Establishment Accept includes the S-NSSAI from the Allowed NS SAI for the VPLMN and also it includes the corresponding S-NSSAI of the HPLMN from the Mapping Of Allowed NSSAI that SMF received in step 3.
If the PDU Session being established was requested to be an always-on PDU Session, the SMF shall indicate whether the request is accepted by including an Always-on PDU Session Granted indication in the PDU Session Establishment Accept message. If the PDU Session being established was not requested to be an always-on PDU Session but the SMF determines that the PDU Session needs to be established as an always-on PDU Session, the SMF shall include an Always-on PDU Session Granted indication in the PDU Session Establishment Accept message indicating that the PDU session is an always-on PDU Session.
If Control Plane CIoT 5GS Optimisation is enabled for this PDU session, the N2 SM information is not included in this step. If Control Plane CIoT 5GS optimisation is enabled for this PDU session, and the UE has sent the Header Compression Configuration in the PDU Session Establishment Request, and the SMF supports the header compression parameters, the SMF shall include the Header Compression Configuration in the PDU Session Establishment Accept message. If the UE has included Header Compression context parameters in Header Compression Configuration in the PDU Session Establishment Request, the SMF shall establish the header compression context and may acknowledge the Header Compression context parameters. If the header compression context is not established during the PDU Session Establishment procedure, before using the compressed format for sending the data, the UE and the SMF need to establish the header compression context based on the Header Compression Configuration. If the SMF has received the Control Plane Only Indicator in step 3, the SMF shall include the Control Plane Only Indicator in the PDU Session Establishment Accept message. The SMF shall indicate the use of Control Plane only on its CDR. If the Small Data Rate Control is configured in the SMF, the SMF shall also include Small Data Rate Control parameters and the Small Data Rate Control Status (if received from the AMF) in the PDU Session Establishment Accept message as described in clause 5.31.14.3 of TS 23.501 [2], If the Serving PLMN intends to enforce Serving PLMN Rate Control (see clause 5.31.14.2 of TS 23.501 [2]) for this PDU session then the SMF shall include the Serving PLMN Rate Control parameters in the PDU Session Establishment Accept message. The UE shall store and use Serving PLMN Rate Control parameters as the maximum allowed limit of uplink control plane user data.
If the UE indicates the support of RDS in the PCO in the PDU Session Establishment Request and RDS is enabled for the PDU Session, the SMF shall inform the UE that RDS is enabled in the PCO in the PDU Session Establishment Accept (see clause 5.31.6 of TS 23.501 [2]).
If the NIDD parameters (e.g., maximum packet size) were received from NEF during the SMF-NEF Connection Establishment procedure in step 10, the SMF shall inform the UE of the NIDD parameters in the PCO in the PDU Session Establishment Accept (see clause 5.31.5 of TS 23.501 [2]).
Multiple QoS Rules, QoS Flow level QoS parameters if needed for the QoS Flow(s) associated with those QoS rule(s) and QoS Profiles may be included in the PDU Session Establishment Accept within the N1 SM and in the N2 SM information.
The Namf_Communication_NlN2MessageTransfer contains the PDU Session ID allowing the AMF to know which access towards the UE to use.
If the PDU session establishment failed anywhere between step 5 and step 11, then the Namf_Communication_NlN2MessageTransfer request shall include the N1 SM container with a PDU Session Establishment Reject message (see clause 8.3.3 of TS 24.501 [25]) and shall not include any N2 SM container. The (R)AN sends the NAS message containing the PDU Session Establishment Reject to the UE. In this case, steps 12-17 are skipped. 12. AMF to (R)AN: N2 PDU Session Request (N2 SM information, NAS message (PDU Session ID, N1 SM container (PDU Session Establishment Accept)), [CN assisted RAN parameters tuning]). If the N2 SM information is not included in the step 11, an N2 Downlink NAS Transport message is used instead.
The AMF sends the NAS message containing PDU Session ID and PDU Session Establishment Accept targeted to the UE and the N2 SM information received from the SMF within the N2 PDU Session Request to the (R)AN.
If the SMF derived CN assisted RAN parameters tuning are stored for the activated PDU Session(s), the AMF may derive updated CN assisted RAN parameters tuning and provide them the (R)AN.
13. (R)AN to UE: The (R)AN may issue AN specific signalling exchange with the UE that is related with the information received from SMF. For example, in the case of a NG-RAN, an RRC Connection Reconfiguration may take place with the UE establishing the necessary NG- RAN resources related to the QoS Rules for the PDU Session request received in step 12.
(R)AN also allocates (R)AN Tunnel Info for the PDU Session. In the case of Dual Connectivity, the Master RAN node may assign some (zero or more) QFIs to be setup to a Master RAN node and others to the Secondary RAN node. The AN Tunnel Info includes a tunnel endpoint for each involved (R)AN node, and the QFIs assigned to each tunnel endpoint. A QFI can be assigned to either the Master RAN node or the Secondary RAN node and not to both.
If the (R)AN receives two CN Tunnel Info for a PDU session in step 12 for redundant transmission, (R)AN also allocates two AN Tunnel Info correspondingly, and indicate to SMF one of the AN Tunnel Info is used as the redundancy tunnel of the PDU session as described in clause 5.33.2.2 of TS 23.501 [2],
(R)AN forwards the NAS message (PDU Session ID, N 1 SM container (PDU Session Establishment Accept)) provided in step 12 to the UE. (R)AN shall only provide the NAS message to the UE if the AN specific signalling exchange with the UE includes the (R)AN resource additions associated to the received N2 command.
If MICO mode is active and the NAS message Request Type in step 1 indicated "Emergency Request", then the UE and the AMF shall locally deactivate MICO mode.
If the N2 SM information is not included in the step 11, then the following steps 14 to 16b and step 17 are omitted.
14. (R)AN to AMF: N2 PDU Session Response (PDU Session ID, Cause, N2 SM information (PDU Session ID, AN Tunnel Info, List of accepted/rejected QFI(s), User Plane Enforcement Policy Notification)). The AN Tunnel Info corresponds to the Access Network address of the N3 tunnel corresponding to the PDU Session.
If the (R)AN rejects QFI(s) the SMF is responsible of updating the QoS rules and QoS Flow level QoS parameters if needed for the QoS Flow associated with the QoS rule(s) in the UE accordingly.
The NG-RAN rejects the establishment of UP resources for the PDU Session when it cannot fulfil User Plane Security Enforcement information with a value of Required. The NG- RAN notifies the SMF when it cannot fulfil a User Plane Security Enforcement with a value of Preferred.
If the NG-RAN cannot establish redundant user plane for the PDU Session as indicated by the RSN parameter, the NG-RAN takes the decision on whether to reject the establishment of RAN resources for the PDU Session based on local policies as described in TS 23.501 [2],
15. AMF to SMF: Nsmf PDUSession UpdateSMContext Request (SM Context ID, N2 SM information, Request Type).
The AMF forwards the N2 SM information received from (R)AN to the SMF.
If the list of rejected QFI(s) is included in N2 SM information, the SMF shall release the rejected QFI(s) associated QoS profiles.
If the N2 SM information indicates failure of user plane resource setup, the SMF shall reject the PDU session establishment by including a N1 SM container with a PDU Session Establishment Reject message (see clause 8.3.3 of TS 24.501 [25]) in the Nsmf PDUSession UpdateSMContext Response in step 17. Step 16 is skipped in this case and instead the SMF releases the N4 Session with UPF.
If the User Plane Enforcement Policy Notification in the N2 SM information indicates that no user plane resources could be established, and the User Plane Enforcement Policy indicated "required" as described in clause 5.10.3 of TS 23.501 [2], the SMF shall reject the PDU session establishment by including a N1 SM container with a PDU Session Establishment Rej ect message (see clause 8.3.3 of TS 24.501 [25]) in the Nsmf_PDUSession_UpdateSMContext Response in step 17. Step 16 is skipped in this case.
16a. The SMF initiates an N4 Session Modification procedure with the UPF. The SMF provides AN Tunnel Info to the UPF as well as the corresponding forwarding rules.
If SMF decides to perform redundant transmission for one or more QoS Flows of the PDU, the SMF also indicates the UPF to perform packet duplication for the QoS Flow(s) in downlink direction by forwarding rules.
In the case of redundant transmission with two I-UPFs for one or more QoS Flows of the PDU, the SMF provides AN Tunnel Info to two I-UPFs and also indicates the UPF (PSA) to perform packet duplication for the QoS Flow(s) in downlink direction by forwarding rules. The SMF also provides the UL Tunnel Info of the UPF (PSA) to the two I-UPFs and the DL Tunnel Info of the two I-UPFs to the UPF (PSA).
NOTE 10: If the PDU Session Establishment Request was due to mobility between 3GPP and non-3GPP access or mobility from EPC, the downlink data path is switched towards the target access in this step.
16b. The UPF provides an N4 Session Modification Response to the SMF.
If multiple UPFs are used in the PDU Session, the UPF in step 16 refers to the UPF terminating N3.
After this step, the UPF delivers any down-link packets to the UE that may have been buffered for this PDU Session.
16c. If Request Type in step 3 indicates neither "Emergency Request" nor "Existing Emergency PDU Session" and, if the SMF has not yet registered for this PDU Session, then the SMF registers with the UDM using Nudm_UECM_Registration (SUPI, DNN, S-NSSAI, PDU Session ID, SMF Identity, Serving PLMN ID, [NID]) for a given PDU Session. As a result, the UDM stores following information: SUPI, SMF identity and the associated DNN, S-NSSAI, PDU Session ID and Serving Network (PLMN ID, [NID], see clause 5.18 of TS 23.501 [2]). The UDM may further store this information in UDR by Nudr DM Update (SUPI, Subscription Data, UE context in SMF data).
If the Request Type received in step 3 indicates "Emergency Request" :
For an authenticated non-roaming UE, based on operator configuration (e.g. related with whether the operator uses a fixed SMF for Emergency calls, etc.), the SMF may register in the UDM using Nudm UECM Regi strati on (SUPI, PDU Session ID, SMF identity, Indication of Emergency Services) for a given PDU Session that is applicable for emergency services. As a result, the UDM shall store the applicable PDU Session for Emergency services.
For an unauthenticated UE or a roaming UE, the SMF shall not register in the UDM for a given PDU Session.
17. SMF to AMF : Nsmf_PDUSession_UpdateSMContext Response (Cause).
The SMF may subscribe to the UE mobility event notification from the AMF (e.g. location reporting, UE moving into or out of Area Of Interest), after this step by invoking Namf_EventExposure_Subscribe service operation as specified in clause 5.2.2.3.2. For LADN, the SMF subscribes to the UE moving into or out of LADN service area event notification by providing the LADN DNN as an indicator for the Area Of Interest (see clause 5.6.5 and 5.6.11 of TS 23.501 [2]).
After this step, the AMF forwards relevant events subscribed by the SMF. 18. [Conditional] SMF to AMF: Nsmf_PDUSession_SMContextStatusNotify (Release)
If during the procedure, any time after step 5, the PDU Session establishment is not successful, the SMF informs the AMF by invoking Nsmf_PDUSession_SMContextStatusNotify (Release). The SMF also releases any N4 session(s) created, any PDU Session address if allocated (e.g. IP address) and releases the association with PCF, if any. In this case, step 19 is skipped.
19. SMF to UE: In the case of PDU Session Type IPv6 or IPv4v6, the SMF generates an IPv6 Router Advertisement and sends it to the UE. If Control Plane CIoT 5GS Optimisation is enabled for this PDU Session the SMF sends the IPv6 Router Advertisement via the AMF for transmission to the UE using the Mobile Terminated Data Transport in Control Plane CIoT 5GS Optimisation procedures (see clause 4.24.2), otherwise the SMF sends the IPv6 Router Advertisement via N4 and the UPF.
20. If the UE has indicated support of transferring Port Management Information Containers, then SMF informs PCF that a 5GS Bridge information is available. SMF also includes the port number of the DS-TT Ethernet port, MAC address of the DS-TT Ethernet port, 5GS Bridge ID, Port Management Information Container and UE-DS-TT Residence Time as provided by the UE. AF calculates the bridge delay for each port pair, e.g. composed of DS-TT Ethernet port and NW-TT Ethernet port, using the UE-DS-TT Residence Time for all NW-TT Ethernet port(s) serving the 5GS Bridge indicated by the 5GS Bridge ID. The SMF may inform PCF that a manageable NW-TT Ethernet port has been detected. If SMF received a Port Management Information Container from the UPF, then SMF provides the Port Management Information Container to the PCF as described in clause 5.28.3.2 of TS 23.501 [2],
21. If the PDU Session establishment failed after step 4, the SMF shall perform the following:
The SMF unsubscribes to the modifications of Session Management Subscription data for the corresponding (SUPI, DNN, S-NSSAI of the HPLMN), using Nudm_SDM_Unsub scribe (SUPI, Session Management Subscription data, DNN, S-NSSAI of the HPLMN), if the SMF is no more handling a PDU Session of the UE for this (DNN, S-NSSAI of the HPLMN). The UDM may unsubscribe to the modification notification from UDR by Nudr DM Unsubscribe (SUPI, Subscription Data, Session Management Subscription data, S-NSSAI of the HPLMN, DNN).
EXAMPLE TECHNIQUES
Figure 15 illustrates an example technique 1500 related to identity management in fifth generation systems, in accordance with various embodiments. In some embodiments, the technique may be performed by an electronic device in a 5G network. The electronic device may be, for example, an electronic device that implements an AF entity in the 5G network.
The technique 1500 may include generating, at 1505, an AF request that includes an indication of an associated entity of a UE or an eRG that is to be added to the network. The associated entity may be, e.g., an entity that does not have an existing subscription to the 5G network. The associated entity may be a PRAS or a PIN entity. The AF request may be, e.g., a Nnef_ServiceParameter request message.
The technique 1500 may further include transmitting, at 1510, the indication of the associated entity to a PCF via a NEF of the 5G network.
Figure 16 illustrates an alternative example technique 1600 related to identity management in fifth generation systems, in accordance with various embodiments. The technique may be performed by an electronic device of a 5G network such as a gateway UE or an eRG.
The technique 1600 may include identifying, at 1605, one or more capabilities of the electronic device, wherein the one or more capabilities are related to federated identity services of the 5G network. The one or more capabilities may be, for example, data network proxy or DN-AAA.
The technique 1600 may further include generating, at 1610, a registration request message related to the one or more capabilities. The technique 1600 may further include transmitting, at 1615, the registration request message to an entity of a core network of the 5G network. The entity may be, for example, an AMF of the core network.
It will be understood that the above-described example techniques 1500 and 1600 are intended as examples of some embodiments of the present disclosure. Other embodiments may include more or fewer elements, different elements, elements in a different order than depicted, etc. Other embodiments may vary.
SYSTEMS AND IMPLEMENTATIONS
Figures 17-19 illustrate various systems, devices, and components that may implement aspects of disclosed embodiments.
Figure 17 illustrates a network 1700 in accordance with various embodiments. The network 1700 may operate in a manner consistent with 3GPP technical specifications for LTE or 5G/NR systems. However, the example embodiments are not limited in this regard and the described embodiments may apply to other networks that benefit from the principles described herein, such as future 3GPP systems, or the like.
The network 1700 may include a UE 1702, which may include any mobile or non-mobile computing device designed to communicate with a RAN 1704 via an over-the-air connection. The UE 1702 may be communicatively coupled with the RAN 1704 by a Uu interface. The UE 1702 may be, but is not limited to, a smartphone, tablet computer, wearable computer device, desktop computer, laptop computer, in-vehicle infotainment, in-car entertainment device, instrument cluster, head-up display device, onboard diagnostic device, dashtop mobile equipment, mobile data terminal, electronic engine management system, electronic/engine control unit, electronic/engine control module, embedded system, sensor, microcontroller, control module, engine management system, networked appliance, machine-type communication device, M2M or D2D device, loT device, etc.
In some embodiments, the network 1700 may include a plurality of UEs coupled directly with one another via a sidelink interface. The UEs may be M2M/D2D devices that communicate using physical sidelink channels such as, but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc.
In some embodiments, the UE 1702 may additionally communicate with an AP 1706 via an over-the-air connection. The AP 1706 may manage a WLAN connection, which may serve to offload some/all network traffic from the RAN 1704. The connection between the UE 1702 and the AP 1706 may be consistent with any IEEE 802.11 protocol, wherein the AP 1706 could be a wireless fidelity (Wi-Fi®) router. In some embodiments, the UE 1702, RAN 1704, and AP 1706 may utilize cellular- WLAN aggregation (for example, LWA/LWIP). Cellular- WLAN aggregation may involve the UE 1702 being configured by the RAN 1704 to utilize both cellular radio resources and WLAN resources.
The RAN 1704 may include one or more access nodes, for example, AN 1708. AN 1708 may terminate air-interface protocols for the UE 1702 by providing access stratum protocols including RRC, PDCP, RLC, MAC, and LI protocols. In this manner, the AN 1708 may enable data/voice connectivity between CN 1720 and the UE 1702. In some embodiments, the AN 1708 may be implemented in a discrete device or as one or more software entities running on server computers as part of, for example, a virtual network, which may be referred to as a CRAN or virtual baseband unit pool. The AN 1708 be referred to as a BS, gNB, RAN node, eNB, ng-eNB, NodeB, RSU, TRxP, TRP, etc. The AN 1708 may be a macrocell base station or a low power base station for providing femtocells, picocells or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.
In embodiments in which the RAN 1704 includes a plurality of ANs, they may be coupled with one another via an X2 interface (if the RAN 1704 is an LTE RAN) or an Xn interface (if the RAN 1704 is a 5G RAN). The X2/Xn interfaces, which may be separated into control/user plane interfaces in some embodiments, may allow the ANs to communicate information related to handovers, data/context transfers, mobility, load management, interference coordination, etc. The ANs of the RAN 1704 may each manage one or more cells, cell groups, component carriers, etc. to provide the UE 1702 with an air interface for network access. The UE 1702 may be simultaneously connected with a plurality of cells provided by the same or different ANs of the RAN 1704. For example, the UE 1702 and RAN 1704 may use carrier aggregation to allow the UE 1702 to connect with a plurality of component carriers, each corresponding to a Pcell or Scell. In dual connectivity scenarios, a first AN may be a master node that provides an MCG and a second AN may be secondary node that provides an SCG. The first/second ANs may be any combination of eNB, gNB, ng-eNB, etc.
The RAN 1704 may provide the air interface over a licensed spectrum or an unlicensed spectrum. To operate in the unlicensed spectrum, the nodes may use LAA, eLAA, and/or feLAA mechanisms based on CA technology with PCells/Scells. Prior to accessing the unlicensed spectrum, the nodes may perform medium/carrier-sensing operations based on, for example, a listen-before-talk (LBT) protocol.
In V2X scenarios the UE 1702 or AN 1708 may be or act as a RSU, which may refer to any transportation infrastructure entity used for V2X communications. An RSU may be implemented in or by a suitable AN or a stationary (or relatively stationary) UE. An RSU implemented in or by: a UE may be referred to as a “UE-type RSU”; an eNB may be referred to as an “eNB-type RSU”; a gNB may be referred to as a “gNB-type RSU”; and the like. In one example, an RSU is a computing device coupled with radio frequency circuitry located on a roadside that provides connectivity support to passing vehicle UEs. The RSU may also include internal data storage circuitry to store intersection map geometry, traffic statistics, media, as well as applications/software to sense and control ongoing vehicular and pedestrian traffic. The RSU may provide very low latency communications required for high speed events, such as crash avoidance, traffic warnings, and the like. Additionally or alternatively, the RSU may provide other cellular/WLAN communications services. The components of the RSU may be packaged in a weatherproof enclosure suitable for outdoor installation, and may include a network interface controller to provide a wired connection (e.g., Ethernet) to a traffic signal controller or a backhaul network.
In some embodiments, the RAN 1704 may be an LTE RAN 1710 with eNBs, for example, eNB 1712. The LTE RAN 1710 may provide an LTE air interface with the following characteristics: SCS of 15 kHz; CP-OFDM waveform for DL and SC-FDMA waveform for UL; turbo codes for data and TBCC for control; etc. The LTE air interface may rely on CSI-RS for CSI acquisition and beam management; PDSCH/PDCCH DMRS for PDSCH/PDCCH demodulation; and CRS for cell search and initial acquisition, channel quality measurements, and channel estimation for coherent demodulation/detection at the UE. The LTE air interface may operating on sub-6 GHz bands.
In some embodiments, the RAN 1704 may be an NG-RAN 1714 with gNBs, for example, gNB 1716, or ng-eNBs, for example, ng-eNB 1718. The gNB 1716 may connect with 5G-enabled UEs using a 5GNR interface. The gNB 1716 may connect with a 5G core through an NG interface, which may include an N2 interface or an N3 interface. The ng-eNB 1718 may also connect with the 5G core through an NG interface, but may connect with a UE via an LTE air interface. The gNB 1716 and the ng-eNB 1718 may connect with each other over an Xn interface.
In some embodiments, the NG interface may be split into two parts, an NG user plane (NG-U) interface, which carries traffic data between the nodes of the NG-RAN 1714 and a UPF 1748 (e.g., N3 interface), and an NG control plane (NG-C) interface, which is a signaling interface between the nodes of the NG-RAN1714 and an AMF 1744 (e.g., N2 interface).
The NG-RAN 1714 may provide a 5G-NR air interface with the following characteristics: variable SCS; CP-OFDM for DL, CP-OFDM and DFT-s-OFDM for UL; polar, repetition, simplex, and Reed-Muller codes for control and LDPC for data. The 5G-NR air interface may rely on CSI-RS, PDSCH/PDCCH DMRS similar to the LTE air interface. The 5G-NR air interface may not use a CRS, but may use PBCH DMRS for PBCH demodulation; PTRS for phase tracking for PDSCH; and tracking reference signal for time tracking. The 5G-NR air interface may operating on FR1 bands that include sub-6 GHz bands or FR2 bands that include bands from 24.25 GHz to 52.6 GHz. The 5G-NR air interface may include an SSB that is an area of a downlink resource grid that includes PSS/SSS/PBCH.
In some embodiments, the 5G-NR air interface may utilize BWPs for various purposes. For example, BWP can be used for dynamic adaptation of the SCS. For example, the UE 1702 can be configured with multiple BWPs where each BWP configuration has a different SCS. When a BWP change is indicated to the UE 1702, the SCS of the transmission is changed as well. Another use case example of BWP is related to power saving. In particular, multiple BWPs can be configured for the UE 1702 with different amount of frequency resources (for example, PRBs) to support data transmission under different traffic loading scenarios. A BWP containing a smaller number of PRBs can be used for data transmission with small traffic load while allowing power saving at the UE 1702 and in some cases at the gNB 1716. A BWP containing a larger number of PRBs can be used for scenarios with higher traffic load.
The RAN 1704 is communicatively coupled to CN 1720 that includes network elements to provide various functions to support data and telecommunications services to customers/subscribers (for example, users of UE 1702). The components of the CN 1720 may be implemented in one physical node or separate physical nodes. In some embodiments, NFV may be utilized to virtualize any or all of the functions provided by the network elements of the CN 1720 onto physical compute/storage resources in servers, switches, etc. A logical instantiation of the CN 1720 may be referred to as a network slice, and a logical instantiation of a portion of the CN 1720 may be referred to as a network sub-slice.
In some embodiments, the CN 1720 may be an LTE CN 1722, which may also be referred to as an EPC. The LTE CN 1722 may include MME 1724, SGW 1726, SGSN 1728, HSS 1730, PGW 1732, and PCRF 1734 coupled with one another over interfaces (or “reference points”) as shown. Functions of the elements of the LTE CN 1722 may be briefly introduced as follows.
The MME 1724 may implement mobility management functions to track a current location of the UE 1702 to facilitate paging, bearer activation/deactivation, handovers, gateway selection, authentication, etc.
The SGW 1726 may terminate an SI interface toward the RAN and route data packets between the RAN and the LTE CN 1722. The SGW 1726 may be a local mobility anchor point for inter-RAN node handovers and also may provide an anchor for inter-3 GPP mobility. Other responsibilities may include lawful intercept, charging, and some policy enforcement.
The SGSN 1728 may track a location of the UE 1702 and perform security functions and access control. In addition, the SGSN 1728 may perform inter-EPC node signaling for mobility between different RAT networks; PDN and S-GW selection as specified by MME 1724; MME selection for handovers; etc. The S3 reference point between the MME 1724 and the SGSN 1728 may enable user and bearer information exchange for inter-3 GPP access network mobility in idle/active states.
The HSS 1730 may include a database for network users, including subscription-related information to support the network entities’ handling of communication sessions. The HSS 1730 can provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, etc. An S6a reference point between the HSS 1730 and the MME 1724 may enable transfer of subscription and authentication data for authenticating/authorizing user access to the LTE CN 1720.
The PGW 1732 may terminate an SGi interface toward a data network (DN) 1736 that may include an application/content server 1738. The PGW 1732 may route data packets between the LTE CN 1722 and the data network 1736. The PGW 1732 may be coupled with the SGW 1726 by an S5 reference point to facilitate user plane tunneling and tunnel management. The PGW 1732 may further include a node for policy enforcement and charging data collection (for example, PCEF). Additionally, the SGi reference point between the PGW 1732 and the data network 17 36 may be an operator external public, a private PDN, or an intra-operator packet data network, for example, for provision of IMS services. The PGW 1732 may be coupled with a PCRF 1734 via a Gx reference point. The PCRF 1734 is the policy and charging control element of the LTE CN 1722. The PCRF 1734 may be communicatively coupled to the app/content server 1738 to determine appropriate QoS and charging parameters for service flows. The PCRF 1732 may provision associated rules into a PCEF (via Gx reference point) with appropriate TFT and QCI.
In some embodiments, the CN 1720 may be a 5GC 1740. The 5GC 1740 may include an AUSF 1742, AMF 1744, SMF 1746, UPF 1748, NSSF 1750, NEF 1752, NRF 1754, PCF 1756, UDM 1758, and AF 1760 coupled with one another over interfaces (or “reference points”) as shown. Functions of the elements of the 5GC 1740 may be briefly introduced as follows.
The AUSF 1742 may store data for authentication of UE 1702 and handle authentication- related functionality. The AUSF 1742 may facilitate a common authentication framework for various access types. In addition to communicating with other elements of the 5GC 1740 over reference points as shown, the AUSF 1742 may exhibit an Nausf service-based interface.
The AMF 1744 may allow other functions of the 5GC 1740 to communicate with the UE 1702 and the RAN 1704 and to subscribe to notifications about mobility events with respect to the UE 1702. The AMF 1744 may be responsible for registration management (for example, for registering UE 1702), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization. The AMF 1744 may provide transport for SM messages between the UE 1702 and the SMF 1746, and act as a transparent proxy for routing SM messages. AMF 1744 may also provide transport for SMS messages between UE 1702 and an SMSF. AMF 1744 may interact with the AUSF 1742 and the UE 1702 to perform various security anchor and context management functions. Furthermore, AMF 1744 may be a termination point of a RAN CP interface, which may include or be an N2 reference point between the RAN 1704 and the AMF 1744; and the AMF 1744 may be a termination point of NAS (Nl) signaling, and perform NAS ciphering and integrity protection. AMF 1744 may also support NAS signaling with the UE 1702 over an N3 IWF interface.
The SMF 1746 may be responsible for SM (for example, session establishment, tunnel management between UPF 1748 and AN 1708); UE IP address allocation and management (including optional authorization); selection and control of UP function; configuring traffic steering at UPF 1748 to route traffic to proper destination; termination of interfaces toward policy control functions; controlling part of policy enforcement, charging, and QoS; lawful intercept (for SM events and interface to LI system); termination of SM parts of NAS messages; downlink data notification; initiating AN specific SM information, sent via AMF 1744 overN2 to AN 1708; and determining SSC mode of a session. SM may refer to management of a PDU session, and a PDU session or “session” may refer to a PDU connectivity service that provides or enables the exchange of PDUs between the UE 1702 and the data network 1736. The UPF 1748 may act as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point of interconnect to data network 1736, and a branching point to support multi-homed PDU session. The UPF 1748 may also perform packet routing and forwarding, perform packet inspection, enforce the user plane part of policy rules, lawfully intercept packets (UP collection), perform traffic usage reporting, perform QoS handling for a user plane (e.g., packet filtering, gating, UL/DL rate enforcement), perform uplink traffic verification (e.g., SDF- to-QoS flow mapping), transport level packet marking in the uplink and downlink, and perform downlink packet buffering and downlink data notification triggering. UPF 1748 may include an uplink classifier to support routing traffic flows to a data network.
The NSSF 1750 may select a set of network slice instances serving the UE 1702. The NSSF 1750 may also determine allowed NSSAI and the mapping to the subscribed S-NSSAIs, if needed. The NSSF 1750 may also determine the AMF set to be used to serve the UE 1702, or a list of candidate AMFs based on a suitable configuration and possibly by querying the NRF 1754. The selection of a set of network slice instances for the UE 1702 may be triggered by the AMF 1744 with which the UE 1702 is registered by interacting with the NSSF 1750, which may lead to a change of AMF. The NSSF 1750 may interact with the AMF 1744 via an N22 reference point; and may communicate with another NSSF in a visited network via an N31 reference point (not shown). Additionally, the NSSF 1750 may exhibit an Nnssf service-based interface.
The NEF 1752 may securely expose services and capabilities provided by 3 GPP network functions for third party, internal exposure/re-exposure, AFs (e.g., AF 1760), edge computing or fog computing systems, etc. In such embodiments, the NEF 1752 may authenticate, authorize, or throttle the AFs. NEF 1752 may also translate information exchanged with the AF 1760 and information exchanged with internal network functions. For example, the NEF 1752 may translate between an AF-Service-Identifier and an internal 5GC information. NEF 1752 may also receive information from other NFs based on exposed capabilities of other NFs. This information may be stored at the NEF 1752 as structured data, or at a data storage NF using standardized interfaces. The stored information can then be re-exposed by the NEF 1752 to other NFs and AFs, or used for other purposes such as analytics. Additionally, the NEF 1752 may exhibit an Nnef servicebased interface.
The NRF 1754 may support service discovery functions, receive NF discovery requests from NF instances, and provide the information of the discovered NF instances to the NF instances. NRF 1754 also maintains information of available NF instances and their supported services. As used herein, the terms “instantiate,” “instantiation,” and the like may refer to the creation of an instance, and an “instance” may refer to a concrete occurrence of an object, which may occur, for example, during execution of program code. Additionally, the NRF 1754 may exhibit the Nnrf service-based interface.
The PCF 1756 may provide policy rules to control plane functions to enforce them, and may also support unified policy framework to govern network behavior. The PCF 1756 may also implement a front end to access subscription information relevant for policy decisions in a UDR of the UDM 1758. In addition to communicating with functions over reference points as shown, the PCF 1756 exhibit an Npcf service-based interface.
The UDM 1758 may handle subscription-related information to support the network entities’ handling of communication sessions, and may store subscription data of UE 1702. For example, subscription data may be communicated via an N8 reference point between the UDM 1758 and the AMF 1744. The UDM 1758 may include two parts, an application front end and a UDR. The UDR may store subscription data and policy data for the UDM 1758 and the PCF 1756, and/or structured data for exposure and application data (including PFDs for application detection, application request information for multiple UEs 1702) for the NEF 1752. The Nudr service-based interface may be exhibited by the UDR 221 to allow the UDM 1758, PCF 1756, and NEF 1752 to access a particular set of the stored data, as well as to read, update (e.g., add, modify), delete, and subscribe to notification of relevant data changes in the UDR. The UDM may include a UDM- FE, which is in charge of processing credentials, location management, subscription management and so on. Several different front ends may serve the same user in different transactions. The UDM-FE accesses subscription information stored in the UDR and performs authentication credential processing, user identification handling, access authorization, registration/mobility management, and subscription management. In addition to communicating with other NFs over reference points as shown, the UDM 1758 may exhibit the Nudm service-based interface.
The AF 1760 may provide application influence on traffic routing, provide access to NEF, and interact with the policy framework for policy control.
In some embodiments, the 5GC 1740 may enable edge computing by selecting operator/3rd party services to be geographically close to a point that the UE 1702 is attached to the network. This may reduce latency and load on the network. To provide edge-computing implementations, the 5GC 1740 may select a UPF 1748 close to the UE 1702 and execute traffic steering from the UPF 1748 to data network 1736 via the N6 interface. This may be based on the UE subscription data, UE location, and information provided by the AF 1760. In this way, the AF 1760 may influence UPF (re)selection and traffic routing. Based on operator deployment, when AF 1760 is considered to be a trusted entity, the network operator may permit AF 1760 to interact directly with relevant NFs. Additionally, the AF 1760 may exhibit an Naf service-based interface.
The data network 1736 may represent various network operator services, Internet access, or third party services that may be provided by one or more servers including, for example, application/content server 1738.
Figure 18 schematically illustrates a wireless network 1800 in accordance with various embodiments. The wireless network 1800 may include a UE 1802 in wireless communication with an AN 1804. The UE 1802 and AN 1804 may be similar to, and substantially interchangeable with, like-named components described elsewhere herein.
The UE 1802 may be communicatively coupled with the AN 1804 via connection 1806. The connection 1806 is illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols such as an LTE protocol or a 5G NR protocol operating at mmWave or sub-6GHz frequencies.
The UE 1802 may include a host platform 1808 coupled with a modem platform 1810. The host platform 1808 may include application processing circuitry 1812, which may be coupled with protocol processing circuitry 1814 of the modem platform 1810. The application processing circuitry 1812 may run various applications for the UE 1802 that source/sink application data. The application processing circuitry 1812 may further implement one or more layer operations to transmit/receive application data to/from a data network. These layer operations may include transport (for example UDP) and Internet (for example, IP) operations
The protocol processing circuitry 1814 may implement one or more of layer operations to facilitate transmission or reception of data over the connection 1806. The layer operations implemented by the protocol processing circuitry 1814 may include, for example, MAC, RLC, PDCP, RRC and NAS operations.
The modem platform 1810 may further include digital baseband circuitry 1816 that may implement one or more layer operations that are “below” layer operations performed by the protocol processing circuitry 1814 in a network protocol stack. These operations may include, for example, PHY operations including one or more of HARQ-ACK functions, scrambling/descrambling, encoding/decoding, layer mapping/de-mapping, modulation symbol mapping, received symbol/bit metric determination, multi-antenna port precoding/decoding, which may include one or more of space-time, space-frequency or spatial coding, reference signal generation/detection, preamble sequence generation and/or decoding, synchronization sequence generation/detection, control channel signal blind decoding, and other related functions.
The modem platform 1810 may further include transmit circuitry 1818, receive circuitry 1820, RF circuitry 1822, and RF front end (RFFE) 1824, which may include or connect to one or more antenna panels 1826. Briefly, the transmit circuitry 1818 may include a digital -to-analog converter, mixer, intermediate frequency (IF) components, etc.; the receive circuitry 1820 may include an analog-to-digital converter, mixer, IF components, etc.; the RF circuitry 1822 may include a low-noise amplifier, a power amplifier, power tracking components, etc.; RFFE 1824 may include filters (for example, surface/bulk acoustic wave filters), switches, antenna tuners, beamforming components (for example, phase-array antenna components), etc. The selection and arrangement of the components of the transmit circuitry 1818, receive circuitry 1820, RF circuitry 1822, RFFE 1824, and antenna panels 1826 (referred generically as “transmit/receive components”) may be specific to details of a specific implementation such as, for example, whether communication is TDM or FDM, in mmWave or sub-6 gHz frequencies, etc. In some embodiments, the transmit/receive components may be arranged in multiple parallel transmit/receive chains, may be disposed in the same or different chips/modules, etc.
In some embodiments, the protocol processing circuitry 1814 may include one or more instances of control circuitry (not shown) to provide control functions for the transmit/receive components.
A UE reception may be established by and via the antenna panels 1826, RFFE 1824, RF circuitry 1822, receive circuitry 1820, digital baseband circuitry 1816, and protocol processing circuitry 1814. In some embodiments, the antenna panels 1826 may receive a transmission from the AN 1804 by receive-beamforming signals received by a plurality of antennas/antenna elements of the one or more antenna panels 1826.
A UE transmission may be established by and via the protocol processing circuitry 1814, digital baseband circuitry 1816, transmit circuitry 1818, RF circuitry 1822, RFFE 1824, and antenna panels 1826. In some embodiments, the transmit components of the UE 1804 may apply a spatial filter to the data to be transmitted to form a transmit beam emitted by the antenna elements of the antenna panels 1826.
Similar to the UE 1802, the AN 1804 may include a host platform 1828 coupled with a modem platform 1830. The host platform 1828 may include application processing circuitry 1832 coupled with protocol processing circuitry 1834 of the modem platform 1830. The modem platform may further include digital baseband circuitry 1836, transmit circuitry 1838, receive circuitry 1840, RF circuitry 1842, RFFE circuitry 1844, and antenna panels 1846. The components of the AN 1804 may be similar to and substantially interchangeable with like- named components of the UE 1802. In addition to performing data transmission/reception as described above, the components of the AN 1808 may perform various logical functions that include, for example, RNC functions such as radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling.
Figure 19 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein. Specifically, Figure 19 shows a diagrammatic representation of hardware resources 1900 including one or more processors (or processor cores) 1910, one or more memory/storage devices 1920, and one or more communication resources 1930, each of which may be communicatively coupled via a bus 1940 or other interface circuitry. For embodiments where node virtualization (e.g., NFV) is utilized, a hypervisor 1902 may be executed to provide an execution environment for one or more network slices/sub-slices to utilize the hardware resources 1900.
The processors 1910 may include, for example, a processor 1912 and a processor 1914. The processors 1910 may be, for example, a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a DSP such as a baseband processor, an ASIC, an FPGA, a radiofrequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.
The memory/storage devices 1920 may include main memory, disk storage, or any suitable combination thereof. The memory/storage devices 1920 may include, but are not limited to, any type of volatile, non-volatile, or semi-volatile memory such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), Flash memory, solid-state storage, etc.
The communication resources 1930 may include interconnection or network interface controllers, components, or other suitable devices to communicate with one or more peripheral devices 1904 or one or more databases 1906 or other network elements via a network 1908. For example, the communication resources 1930 may include wired communication components (e.g., for coupling via USB, Ethernet, etc.), cellular communication components, NFC components, Bluetooth® (or Bluetooth® Low Energy) components, Wi-Fi® components, and other communication components.
Instructions 1950 may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors 1910 to perform any one or more of the methodologies discussed herein. The instructions 1950 may reside, completely or partially, within at least one of the processors 1910 (e.g., within the processor’s cache memory), the memory/storage devices 1920, or any suitable combination thereof. Furthermore, any portion of the instructions 1950 may be transferred to the hardware resources 1900 from any combination of the peripheral devices 1904 or the databases 1906. Accordingly, the memory of processors 1910, the memory/storage devices 1920, the peripheral devices 1904, and the databases 1906 are examples of computer-readable and machine-readable media. For one or more embodiments, at least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, and/or methods as set forth in the example section below. For example, the baseband circuitry as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below. For another example, circuitry associated with a UE, base station, network element, etc. as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below in the example section.
EXAMPLES
Example 1 may include the method for enabling federated identity management in 5G system.
Example 2 may include the method of example 1 and/or some other example herein, whereby the operator of the 5G system acts as an identifier provider (IdP) responsible for user authentication of services provided in different data network domains including cloud, personal loT networks, residential networks.
Example 3 may include the method of example 2 and/or some other example herein, whereby, for data network domain in residential network, a residential gateway (eRG) interconnects two networks and relay the traffic between residential network and 5G network and provides connectivity to 5G network for associated entity of small indoor base station (PRAS) and non-3GPP devices.
Example 4 may include the method of example 3 and/or some other example herein, whereby the authenticated/authorized eRG adds the information of an associated entity of the eRG to the 5G network, in which the associated entity is regarded as a user with user identity associated to the eRG subscription.
Example 5 may include the method of example 4 and/or some other example herein, whereby each associated entity of the eRG is registered as a data network domain and the eRG acts as a data network proxy for forwarding traffics between the 5G network and the data network domain of the associated entity.
Example 6 may iclude the method of example 5 and/or some other example herein, whereby when the operator authenticates the user identity of the associated non-3GPP device(s) or PRAS(s) of the eRG, the trust can be further established between the non-3GPP device/PRAS and eRG.
Example 7 may include the method of example 6 and/or some other example herein, whereby the non-3GPP device/PRAS continues to create and register user identities to the 5G network for their associated entities including UEs connected to the PRAS and the applications running on the non-3GPP device or connected to it, in which the next level of trust can be further established between the non-3GPP device/PRAS and associated entities.
Example 8 may include the method of example 2 and/or some other example herein, whereby for data network domain in personal loT network (PIN), a UE acting as a gateway interconnects two networks and relay the traffic between residential network and 5G network and provides connectivity to 5G network for associated entity of things including human users, non-3GPP devices, applications running on the UE or connected to the UE.
Examle 9 may include the method of example 8 and/or some other example herein, whereby the authenticated/authorized UE adds the information of an associated entity of the UE to the 5G network, in which the associated entity is regarded as a user with user identity associated to the UE subscription.
Example 10 may include the method of example 9 and/or some other example herein, whereby each associated entity of the UE is registered as a data network domain and the UE acts as a data network proxy for forwarding traffics between the 5G network and the data network domain of the associated entity.
Example 11 may include the method of example 10 and/or some other example herein, whereby when the operator authenticates the user identity of the associated entities of the UE, the trust can be further established between associated entity and the UE.
Example 12 may include the method of examples 10 or example 7 and/or some other example herein, whereby when an associated entity of the UE as a human user is authenticated by the 5G network, the human user using authenticated/authorized UE can access authorized services provided by different authorized data network domains in the clouds, PIN, and residential network.
Exampel 13 may include the method of example 10 or example 7 and/or some other example herein, whereby for allowing an authorized UE to access the service in data network domain of PIN or residential, the authorized UE is configured with information of the data network domains via UE configuration update procedure for transparent UE Policy delivery, which is triggered by PCF in 5G network for updating the following set of information for an authorized data network domain: Authorized DNN(s) of the data network domains, e.g. PIN, Residential network, Allowed S-NSSA(s) of each authorized DNN, Authorized user identifier(s) of the application(s) with user identit(ies) of each authorized DNN.
Example 14 may include the method of example 10 or example 7 and/or some other example herein, whereby the eRG/gateway UE in PIN enables support of Data network proxy and NAT in 5G system. Example 15 may include the method of example 14 and/or some other example herein, whereby eRG/gateway UE subscription includes federated Identity services of 5G network for handling user identities, user profiles, user authentication, service authorization, access control, etc.
Example 16 may include the method of example 15 and/or some other example herein, whereby eRG/gateway UE capabilities include Data network proxy and DN-AAA capabilities.
Example 17 may include the method of example 16 and/or some other example herein, whereby eRG/gateway UE’s registration procedure indicatingeRG/gateway UE capabilities in the registration request message.
Example 18 may include the method of example 17 and/or some other example herein, whereby the eRG/gateway UE uses PDU session modification request procedure to update DN- AAA address information at eRG by indicating a new IE in the request message.
Example 19 may include the method of example 18 and/or some other example herein, whereby when a new non-3GPP device or PRAS is discovered and connected to eRG/gateway UE, the eRG/gateway UE performs registration procedure to register the non-3GPP device or PRAS with user identities, the 5G network allocates DNN information for identifying the data network domain of the associated entity for the eRG/gateway UE.
Example 20 may iclude the method of example 19 and/or some other example herein, whereby the eRG/gateway UE transfers traffic of multiple data network domains for PIN and residential network and the eRG/gateway UE may determine to use the same or different PDU session for transferring traffic of multiple data network domains for PIN and residential.
Example 21 may iclude the method of example 20 and/or some other example herein, whereby if different PDU sessions are used for transporting user plane data for different data network domain of associated entity, the eRG/gateway UE uses PDU session request/modification procedure to provide/update the DNN information of the data network domain for the associated entities.
Example 22 may include the method of example 21 and/or some other example herein, whereby the eRG/gateway UE indicates one or more DNN(s) of data network domain(s) for the associated entity(es) in the new IE in the PDU session request/modification request message.
Example 23 may include the method of example 22 and/or some other example herein, whereby the SMF stores the mapping information between the PDU session ID and one or more DNN(s) of the data network domains for the associated entity of the eRG/gateway UE.
Example 24 may include the method of example 23 and/or some other example herein, whereby eRG/gateway UE acting as DN proxy sends a PDU session establishment request indicating the reliable connection for DN proxy and this PDU session is used for any DN related control plane traffic, e.g. authentication request/response messages.
Example 25 may include the method of example 1, and/or some other example herein, whereby the associated entity (non-3GPP device or PRAS) is connected and associated to the UE or eRG which is regarded as trusted 3GPP devices, the associated entity is dependent on the UE/eRG subscription.
Example 26 may include the method of example 25, and/or some other example herein, whereby the UE subscription includes the Federated Identity Management services for user centric management and authentication provided by the operator.
Example 27 may include the method of example 1, and/or some other example herein, whereby based on UE/eRG subscription and AF provisioned service specific parameter, the PCF performs data network domain configuration and configures user profiles for the associated entity.
Example 28 may include the method of example 27, and/or some other example herein, whereby the PCF creates the one or more user profiles of the associated entity.
Example 29 may include the method of example 28, and/or some other example herein, whereby the allocates at least one of the following information for identifying the data network domain of the associated entity: the DNN, subdomain name, and S-NSSAI. All these data network parameters can be used together to identify a data network service in the PIN/residential environment (CPN).
Example 30 may include the method of example 29, and/or some other example herein, whereby the PCF configures user policy containing information of user identifiers, data network configuration (e.g. DNN, subdomain name, and S-NSSAI), operator’s access control setting for Unified Access Control (used by the eRG to access 5G network for the associated entity), etc. as part of the UE/eRG policy for the associated entity (non-3GPP device, PRAS).
Example 31 may include the method of example 30, and/or some other example herein, where by the PCF performs UE policy delivery
Example 32 may include the method for enabling federated identity management in 5G system.
Example 33 may include the method of example 32 and/or some other example herein, whereby 5G network supports automatic on boarding process for new associated entity of a UE/eRG (both are with PIN Element with Gateway Capability) and the associated entity is a non-3GPP device which does not have 3GPP subscription and 3GPP credentials and may or may not have 3 GPP capability.
Example 34 may include the method of example 33 and/or some other example herein, whereby the 5G network creates and manages a PIN identified by a PIN ID. Example 35 may include the method of example 34 and/or some other example herein, whereby a PIN Element with Gateway Capability in a PIN can request 5G network to on board a PIN Element that is connected to it.
Example 36 may include the method of example 35 and/or some other example herein, whereby the 5G network supports suitable APIs for the third party (application server) to provide configuration information of a PIN Element connected to a PIN Element with Gateway Capability in a PIN.
Example 37 may include the method of example 36 and/or some other example herein, whereby the application server requests 5G network via AF to on board the PIN Element, in which the on boarding request from the UE, including the UE ID, PIN ID (if available) and the configuration information of the non-3GPP device.
Example 38 may include the method of example 37 and/or some other example herein, whereby the 5G network creates an identity that can uniquely identify the PIN Element and associates the PIN Element to the PIN Element with Gateway Capability for the PIN.
Example 39 may include the method of example 38 and/or some other example herein, whereby the 5G network creates the User Profile of the PIN Element and stored the User Profile at the MNOa with configuration information provided by the PIN Element via the UE.
Example 40 may include the method of example 39 and/or some other example herein, whereby if PIN ID is not available, the 5G network creates a PIN ID to uniquely identify the PIN and return the allocated PIN ID to the PIN Element with Gateway Capability for the PIN in the response message.
Example 41 may include the method of example 40 and/or some other example herein, whereby the 5G network sends notification message (including PIN ID, identity of the PIN Element, and authorization of the communications between the PIN Element with Gateway Capability and the PIN Element) to the PIN Element with Gateway Capability which requested to on boarding its associated non-3GPP device.
Example 42 may include the method of example 41 and/or some other example herein, whereby the 5G network authenticates the identity of the first PIN Element within the PIN based on the User Profiles of the PIN Elements in the PIN and manages the authorization and the communication between the first PIN Element and other PIN Elements using PIN direct connection.
Example 43 may include the method of example 42 and/or some other example herein, whereby the 5G network configures and authorizes a PIN Element with Gateway Capability with PIN Element with Management Capability which can manage and configure management and configuration data of the PIN locally. Example 44 may include the method of example 41 and/or some other example herein, whereby the User Profile contains the User Identifier and the configuration of the PIN Element.
Example 45 may include the method of example 44 and/or some other example herein, whereby the configuration of the PIN Element in the User profile contains: Specific configuration settings and parameters, e.g. active/inactive time, number of accesses, etc; Authorized communication methods, e.g. direct network connection, direct device connection, PIN direct connection (e.g. Bluetooth, WLAN, wireline); Authentication/authorization policy and access restriction policy to access the PIN Element or application running on the PIN Element; Credential for 5G network Authentication; Credential information of the authorized users for communicating with the PIN Element.
Example 46 may include the method of example 45 and/or some other example herein, whereby the PIN Element can have one or more User Profile (each is identified by different User Identifier).
Example 47 may include the method of example 46 and/or some other example herein, whereby for the same PIN Element, it can connect to two different gateways with PIN Element Gateway Capability, e.g. UE or eRG.
Example 48 may include the method of example 47 and/or some other exampel herein, whereby when the PIN Element connects to different gateways, it can apply different User Profiles associated to its User Identity and indicates User identifier and the corresponding credentials in the registration request message.
Example 49 may include the method of example 48 and/or some other example herein, whereby the 5G network authenticates the non-3GPP device/PIN Element based on the user identifier and the credentials indicated in the registration request message.
Example 50 may include the method of examples 39 and/or 49 and/or some other example herein, whereby for on boarding a PRAS (without 3GPP subscription and credentials), the 5G network allocates a PRAS ID.
Example 51 may include the method of example 50 and/or some other example herein, whereby the configuration information of the PRAS in the User Profile includes the PRAS radio capabilities (WLAN, wireline or 3 GPP radio capabilities and network capabilities.
Example 52 may include the method of example 51 and/or some other example herein, whereby if the PRAS supports 3GPP radio capabilities, it contains applicable settings, e.g. the carrier frequencies, and IAB capability (via eRG or gNB as donor IAB).
Example 53 may include the method of example 52 and/or some other example herein, whereby if the PRAS supports 3 GPP network capabilities, it contains applicable settings, e.g. NAS for connecting to N3IWF. Example 54 may include the method of example 38 and/or some other example herein, whereby the PIN Element sends the on boarding request to the application server is regarded as offering the permission to add the new associated PIN Element.
Example 55 may include the method of example 54 and/or some other example herein, whereby when the 5G network creates a PIN with a PIN ID. The corresponding PIN configuration is stored, which may be associated to the PIN Element with Gateway Capability.
Example 56 may include the method of example 55 and/or some other example herein, whereby based on the stored PIN information, if the permission of adding a new PIN Element for a PIN is needed from a second PIN Element, e.g. a UE, the 5G network sends a request message asking for the permission from the second PIN Element. With the permission, the 5G network continues on boarding process.
Example 57 may include the method of example 56 and/or some other example herein, whereby if the second PIN Element rejects the permission request, the 5G network rejects the process to add the PIN Element and replies rejection cause in the response message to the PIN Element requesting for on boarding the PIN Element.
Example 58 may include the method of example 57 and/or some other example herein, whereby the permission request is send via NAS message or user plane traffic to the second PIN Element.
Example 59 may include a method to be performed by an electronic device in a fifth generation (5G) network, wherein the method comprises: generating, by the electronic device, an application function (AF) request that includes an indication of an associated entity of a user equipment (UE) or an evolved residential gateway (eRG) that is to be added to the network; and transmitting, by the electronic device, the indication of the associated entity to a Policy Control Function (PCF) via a network exposure function (NEF) of the 5G network.
Example 60 may include the method of example 59, and/or some other example herein, wherein the associated entity is an entity that does not have an existing subscription to the 5G network.
Example 61 may include the method of any of examples 59-60, and/or some other example herein, wherein the electronic device implements an AF entity in the in the 5G network that generates that AF request.
Example 62 may include the method of any of examples 59-61, and/or some other example herein, wherein the AF request is a Nnef ServiceParameter request message.
Example 63 may include the method of any of examples 59-62, and/or some other example herein, wherein the associated entity is a premises radio access station (PRAS) or a personal internet of things (loT) network (PIN) entity. Example 64 may include the method of any of examples 59-63, and/or some other example herein, wherein the indication includes one or more of a user description related to the associated entity, a service description related to the associated entity, service parameters related to the associated entity, and an indication of one or more target UEs related to the associated entity.
Example 65 may include the method of example 64, and/or some other example herein, wherein the user description includes one or more of a user type, a user identifier (ID), and a user profile.
Example 66 may include the method of example 65, and/or some other example herein, wherein the user profile includes one or more of a user identifier, a list of authorized UEs, capability related to authentication support, information related to authentication or authorization policies, 5G network service settings and parameters, and data network parameters.
Example 67 may include the method of any of examples 59-66, and/or some other example herein, wherein the PCF is to create one or more user profiles related to the associated entity based on a subscription of the UE or the eRG and the indication.
Example 68 may include the method of example 67, and/or some other example herein, wherein a user profile of the one or more user profiles includes a DNN (Data Network Name) related to the associated entity, a subdomain name related to the associated entity, and a singlenetwork slice selection assistance information (S-NSSAI) related to the associated entity.
Example 69 may include a method to be performed by an electronic device in a fifth generation (5G) network, wherein the method comprises: identifying, by the electronic device, one or more capabilities of the electronic device, wherein the one or more capabilities are related to federated identity services of the 5G network; generating, by the electronic device, a registration request message related to the one or more capabilities; and transmitting, by the electronic device, the registration request message to an entity of a core network of the 5G network.
Example 70 may include the method of example 69, and/or some other example herein, wherein the entity is an access and mobility management function (AMF) of a core network of the 5G network.
Example 71 may include the method of any of examples 69-70, and/or some other example herein, wherein the one or more capabilities include data network proxy or direct network authentication, authorization, and accounting (DN-AAA).
Example 72 may include the method of any of examples 69-71, and/or some other example herein, wherein the electronic device is a gateway user equipment (UE). Example 73 may include the method of any of examples 69-72, and/or some other example herein, wherein the electronic device is an evolved residential gateway (eRG).
Example 74 may include the method of any of examples 69-73, and/or some other example herein, wherein the method further comprises: identifying, by the electronic device, updated direct network authentication, authorization, and accounting (DN-AAA) address information; generating, by the electronic device, a protocol data unit (PDU) session modification request message that includes an IE related to the updated DN-AAA address information; and transmitting, by the electronic device, the PDU session modification request message to the entity of the core netowork.
Example 75 may include the method of any of examples 69-74, and/or some other example herein, wherein the method further comprises: identifying, by the electronic device, a new device that is communicatively coupled to the electronic device; and registering, by the electronic device, the new device with the entity of the core network.
Example 76 may include the method of example 75, and/or some other example herein, wherein the new device is a premises radio access station (PRAS) or a personal internet of things (loT) network (PIN) entity.
Example 77 may include the method of any of examples 69-76, and/or some other example herein, further comprising: identifying, by the electronic device, a received UE configuration update message; and identifying, by the electronic device based on the UE configuration update message, a service domain of a personal internet of things (loT) network (PIN) entity or a residential network.
Example 78 may include the method of example 77, and/or some other example herein, wherein the UE configuration update message includes one or more of: an indication of one or more authorized domain network names (DNNs) of data network domains associated with the PIN entity or residential network; an indication of allowed single-network slice selection assistance information (S-NSSAIs) of respective ones of the DNNs; and an indication of authorized user identifiers of applications with user identities of respective ones of the DNNs.
Example 79 may include an apparatus comprising means to perform one or more elements of a method described in or related to any of examples 1-78, or any other method or process described herein.
Example 80 may include one or more non-transitory computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of a method described in or related to any of examples 1-78, or any other method or process described herein.
Example 81 may include an apparatus comprising logic, modules, or circuitry to perform one or more elements of a method described in or related to any of examples 1-78, or any other method or process described herein.
Example 82 may include a method, technique, or process as described in or related to any of examples 1-78, or portions or parts thereof.
Example 83 may include an apparatus comprising: one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples 1-78, or portions thereof.
Example 84 may include a signal as described in or related to any of examples 1-78, or portions or parts thereof.
Example 85 may include a datagram, packet, frame, segment, protocol data unit (PDU), or message as described in or related to any of examples 1-78, or portions or parts thereof, or otherwise described in the present disclosure.
Example 86 may include a signal encoded with data as described in or related to any of examples 1-78, or portions or parts thereof, or otherwise described in the present disclosure.
Example 87 may include a signal encoded with a datagram, packet, frame, segment, protocol data unit (PDU), or message as described in or related to any of examples 1-78, or portions or parts thereof, or otherwise described in the present disclosure.
Example 88 may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors is to cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples 1-78, or portions thereof.
Example 89 may include a computer program comprising instructions, wherein execution of the program by a processing element is to cause the processing element to carry out the method, techniques, or process as described in or related to any of examples 1-78, or portions thereof.
Example 90 may include a signal in a wireless network as shown and described herein.
Example 91 may include a method of communicating in a wireless network as shown and described herein.
Example 92 may include a system for providing wireless communication as shown and described herein.
Example 93 may include a device for providing wireless communication as shown and described herein.
Any of the above-described examples may be combined with any other example (or combination of examples), unless explicitly stated otherwise. The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.
Terminology
For the purposes of the present document, the following terms and definitions are applicable to the examples and embodiments discussed herein.
The term “circuitry” as used herein refers to, is part of, or includes hardware components such as an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group), an Application Specific Integrated Circuit (ASIC), a field-programmable device (FPD) (e.g., a field-programmable gate array (FPGA), a programmable logic device (PLD), a complex PLD (CPLD), a high-capacity PLD (HCPLD), a structured ASIC, or a programmable SoC), digital signal processors (DSPs), etc., that are configured to provide the described functionality. In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. The term “circuitry” may also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) with the program code used to carry out the functionality of that program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuitry.
The term “processor circuitry” as used herein refers to, is part of, or includes circuitry capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations, or recording, storing, and/or transferring digital data. Processing circuitry may include one or more processing cores to execute instructions and one or more memory structures to store program and data information. The term “processor circuitry” may refer to one or more application processors, one or more baseband processors, a physical central processing unit (CPU), a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, and/or any other device capable of executing or otherwise operating computerexecutable instructions, such as program code, software modules, and/or functional processes. Processing circuitry may include more hardware accelerators, which may be microprocessors, programmable processing devices, or the like. The one or more hardware accelerators may include, for example, computer vision (CV) and/or deep learning (DL) accelerators. The terms “application circuitry” and/or “baseband circuitry” may be considered synonymous to, and may be referred to as, “processor circuitry.” The term “interface circuitry” as used herein refers to, is part of, or includes circuitry that enables the exchange of information between two or more components or devices. The term “interface circuitry” may refer to one or more hardware interfaces, for example, buses, I/O interfaces, peripheral component interfaces, network interface cards, and/or the like.
The term “user equipment” or “UE” as used herein refers to a device with radio communication capabilities and may describe a remote user of network resources in a communications network. The term “user equipment” or “UE” may be considered synonymous to, and may be referred to as, client, mobile, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, reconfigurable mobile device, etc. Furthermore, the term “user equipment” or “UE” may include any type of wireless/wired device or any computing device including a wireless communications interface.
The term “network element” as used herein refers to physical or virtualized equipment and/or infrastructure used to provide wired or wireless communication network services. The term “network element” may be considered synonymous to and/or referred to as a networked computer, networking hardware, network equipment, network node, router, switch, hub, bridge, radio network controller, RAN device, RAN node, gateway, server, virtualized VNF, NFVI, and/or the like.
The term “computer system” as used herein refers to any type interconnected electronic devices, computer devices, or components thereof. Additionally, the term “computer system” and/or “system” may refer to various components of a computer that are communicatively coupled with one another. Furthermore, the term “computer system” and/or “system” may refer to multiple computer devices and/or multiple computing systems that are communicatively coupled with one another and configured to share computing and/or networking resources.
The term “appliance,” “computer appliance,” or the like, as used herein refers to a computer device or computer system with program code (e.g., software or firmware) that is specifically designed to provide a specific computing resource. A “virtual appliance” is a virtual machine image to be implemented by a hypervisor-equipped device that virtualizes or emulates a computer appliance or otherwise is dedicated to provide a specific computing resource.
The term “resource” as used herein refers to a physical or virtual device, a physical or virtual component within a computing environment, and/or a physical or virtual component within a particular device, such as computer devices, mechanical devices, memory space, processor/CPU time, processor/CPU usage, processor and accelerator loads, hardware time or usage, electrical power, input/output operations, ports or network sockets, channel/link allocation, throughput, memory usage, storage, network, database and applications, workload units, and/or the like. A “hardware resource” may refer to compute, storage, and/or network resources provided by physical hardware element(s). A “virtualized resource” may refer to compute, storage, and/or network resources provided by virtualization infrastructure to an application, device, system, etc. The term “network resource” or “communication resource” may refer to resources that are accessible by computer devices/ systems via a communications network. The term “system resources” may refer to any kind of shared entities to provide services, and may include computing and/or network resources. System resources may be considered as a set of coherent functions, network data objects or services, accessible through a server where such system resources reside on a single host or multiple hosts and are clearly identifiable.
The term “channel” as used herein refers to any transmission medium, either tangible or intangible, which is used to communicate data or a data stream. The term “channel” may be synonymous with and/or equivalent to “communications channel,” “data communications channel,” “transmission channel,” “data transmission channel,” “access channel,” “data access channel,” “link,” “data link,” “carrier,” “radiofrequency carrier,” and/or any other like term denoting a pathway or medium through which data is communicated. Additionally, the term “link” as used herein refers to a connection between two devices through a RAT for the purpose of transmitting and receiving information.
The terms “instantiate,” “instantiation,” and the like as used herein refers to the creation of an instance. An “instance” also refers to a concrete occurrence of an object, which may occur, for example, during execution of program code.
The terms “coupled,” “communicatively coupled,” along with derivatives thereof are used herein. The term “coupled” may mean two or more elements are in direct physical or electrical contact with one another, may mean that two or more elements indirectly contact each other but still cooperate or interact with each other, and/or may mean that one or more other elements are coupled or connected between the elements that are said to be coupled with each other. The term “directly coupled” may mean that two or more elements are in direct contact with one another. The term “communicatively coupled” may mean that two or more elements may be in contact with one another by a means of communication including through a wire or other interconnect connection, through a wireless communication channel or link, and/or the like.
The term “information element” refers to a structural element containing one or more fields. The term “field” refers to individual contents of an information element, or a data element that contains content.
The term “SMTC” refers to an SSB-based measurement timing configuration configured by SSB-MeasurementTimingConfiguration .
The term “SSB” refers to an SS/PBCH block.
The term “a “Primary Cell” refers to the MCG cell, operating on the primary frequency, in which the UE either performs the initial connection establishment procedure or initiates the connection re-establishment procedure.
The term “Primary SCG Cell” refers to the SCG cell in which the UE performs random access when performing the Reconfiguration with Sync procedure for DC operation.
The term “Secondary Cell” refers to a cell providing additional radio resources on top of a Special Cell for a UE configured with CA. The term “Secondary Cell Group” refers to the subset of serving cells comprising the
PSCell and zero or more secondary cells for a UE configured with DC.
The term “Serving Cell” refers to the primary cell for a UE in RRC CONNECTED not configured with CA/DC there is only one serving cell comprising of the primary cell.
The term “serving cell” or “serving cells” refers to the set of cells comprising the Special Cell(s) and all secondary cells for a UE in RRC CONNECTED configured with CA/.
The term “Special Cell” refers to the PCell of the MCG or the PSCell of the SCG for DC operation; otherwise, the term “Special Cell” refers to the Pcell.

Claims

1. A method to be performed by an electronic device in a fifth generation (5G) network, wherein the method comprises: generating, by the electronic device, an application function (AF) request that includes an indication of an associated entity of a user equipment (UE) or an evolved residential gateway (eRG) that is to be added to the network; and transmitting, by the electronic device, the indication of the associated entity to a Policy Control Function (PCF) via a network exposure function (NEF) of the 5G network.
2. The method of claim 1, wherein the associated entity is an entity that does not have an existing subscription to the 5G network.
3. The method of claim 1, wherein the electronic device implements an AF entity in the in the 5G network that generates that AF request.
4. The method of claim 1, wherein the AF request is a Nnef ServiceParameter request message.
5. The method of claim 1, wherein the associated entity is a premises radio access station (PRAS) or a personal internet of things (loT) network (PIN) entity.
6. The method of any of claims 1-5, wherein the indication includes one or more of a user description related to the associated entity, a service description related to the associated entity, service parameters related to the associated entity, and an indication of one or more target UEs related to the associated entity.
7. The method of claim 6, wherein the user description includes one or more of a user type, a user identifier (ID), and a user profile.
8. The method of claim 7, wherein the user profile includes one or more of a user identifier, a list of authorized UEs, capability related to authentication support, information related to authentication or authorization policies, 5G network service settings and parameters, and data network parameters.
86
9. The method of claim 1, wherein the PCF is to create one or more user profiles related to the associated entity based on a subscription of the UE or the eRG and the indication.
10. The method of claim 9, wherein a user profile of the one or more user profiles includes a DNN (Data Network Name) related to the associated entity, a subdomain name related to the associated entity, and a single-network slice selection assistance information (S- NSSAI) related to the associated entity.
11. A method to be performed by an electronic device in a fifth generation (5G) network, wherein the method comprises: identifying, by the electronic device, one or more capabilities of the electronic device, wherein the one or more capabilities are related to federated identity services of the 5G network; generating, by the electronic device, a registration request message related to the one or more capabilities; and transmitting, by the electronic device, the registration request message to an entity of a core network of the 5G network.
12. The method of claim 11, wherein the entity is an access and mobility management function (AMF) of a core network of the 5G network.
13. The method of claim 11, wherein the one or more capabilities include data network proxy or direct network authentication, authorization, and accounting (DN-AAA).
14. The method of claim 11, wherein the electronic device is a gateway user equipment (UE).
15. The method of claim 11, wherein the electronic device is an evolved residential gateway (eRG).
16. The method of any of claims 11-15, wherein the method further comprises: identifying, by the electronic device, updated direct network authentication, authorization, and accounting (DN-AAA) address information; generating, by the electronic device, a protocol data unit (PDU) session modification request message that includes an IE related to the updated DN-AAA address information; and transmitting, by the electronic device, the PDU session modification request message to
87 the entity of the core netowork.
17. The method of any of claims 11-15, wherein the method further comprises: identifying, by the electronic device, a new device that is communicatively coupled to the electronic device; and registering, by the electronic device, the new device with the entity of the core network.
18. The method of claim 17, wherein the new device is a premises radio access station (PRAS) or a personal internet of things (loT) network (PIN) entity.
19. The method of any of claims 11-15, further comprising: identifying, by the electronic device, a received UE configuration update message; and identifying, by the electronic device based on the UE configuration update message, a service domain of a personal internet of things (loT) network (PIN) entity or a residential network.
20. The method of claim 19, wherein the UE configuration update message includes one or more of: an indication of one or more authorized domain network names (DNNs) of data network domains associated with the PIN entity or residential network; an indication of allowed single-network slice selection assistance information (S- NSSAIs) of respective ones of the DNNs; and an indication of authorized user identifiers of applications with user identities of respective ones of the DNNs.
PCT/US2022/013338 2021-01-25 2022-01-21 Federated identity management in fifth generation (5g) system WO2022159725A1 (en)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US202163141386P 2021-01-25 2021-01-25
US63/141,386 2021-01-25
US202163151587P 2021-02-19 2021-02-19
US63/151,587 2021-02-19
US202163181886P 2021-04-29 2021-04-29
US63/181,886 2021-04-29

Publications (1)

Publication Number Publication Date
WO2022159725A1 true WO2022159725A1 (en) 2022-07-28

Family

ID=82549903

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2022/013338 WO2022159725A1 (en) 2021-01-25 2022-01-21 Federated identity management in fifth generation (5g) system

Country Status (1)

Country Link
WO (1) WO2022159725A1 (en)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024031392A1 (en) * 2022-08-09 2024-02-15 北京小米移动软件有限公司 Personal iot network information updating method and apparatus, communication device and storage medium
WO2024032612A1 (en) * 2022-08-10 2024-02-15 中国电信股份有限公司 Communication method and system, and computer-readable storage medium
WO2024036001A1 (en) * 2022-08-10 2024-02-15 Apple Inc. Authentication enhancements for personal iot networks
WO2024037256A1 (en) * 2022-08-16 2024-02-22 华为技术有限公司 Service flow routing method and apparatus
WO2024061145A1 (en) * 2022-09-20 2024-03-28 维沃移动通信有限公司 Gateway information use method and apparatus, terminal, and network side device
WO2024067331A1 (en) * 2022-09-28 2024-04-04 维沃移动通信有限公司 Device switching method in personal internet of things network, and communication method and device
WO2024094289A1 (en) * 2022-11-01 2024-05-10 Telefonaktiebolaget Lm Ericsson (Publ) Secure management of personal iot networks (pins)
EP4395391A1 (en) * 2022-12-28 2024-07-03 T-Mobile Innovations LLC User equipment clusters for network registration and authentication

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105072088A (en) * 2010-01-22 2015-11-18 交互数字专利控股公司 Method and apparatus for trusted federated identity management and data access authorization
US10524198B2 (en) * 2018-05-18 2019-12-31 Intel Corporation UE indication to PCF whether or not to send UE policy
US20200280888A1 (en) * 2017-11-27 2020-09-03 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Method and Apparatus for Negotiation of User Equipment Policy Delivery
US20210007166A1 (en) * 2019-08-01 2021-01-07 Ching-Yu LIAO Multiconnectivity function in application cloud for 5g systems

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105072088A (en) * 2010-01-22 2015-11-18 交互数字专利控股公司 Method and apparatus for trusted federated identity management and data access authorization
US20200280888A1 (en) * 2017-11-27 2020-09-03 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Method and Apparatus for Negotiation of User Equipment Policy Delivery
US10524198B2 (en) * 2018-05-18 2019-12-31 Intel Corporation UE indication to PCF whether or not to send UE policy
US20210007166A1 (en) * 2019-08-01 2021-01-07 Ching-Yu LIAO Multiconnectivity function in application cloud for 5g systems

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Support of multi-device and multi-identity in the IP Multimedia Subsystem (IMS); Stage 3 (Release 17)", 3GPP DRAFT; DRAFT_24174-H10, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, 10 December 2020 (2020-12-10), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051966142 *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024031392A1 (en) * 2022-08-09 2024-02-15 北京小米移动软件有限公司 Personal iot network information updating method and apparatus, communication device and storage medium
WO2024032612A1 (en) * 2022-08-10 2024-02-15 中国电信股份有限公司 Communication method and system, and computer-readable storage medium
WO2024036001A1 (en) * 2022-08-10 2024-02-15 Apple Inc. Authentication enhancements for personal iot networks
WO2024037256A1 (en) * 2022-08-16 2024-02-22 华为技术有限公司 Service flow routing method and apparatus
WO2024061145A1 (en) * 2022-09-20 2024-03-28 维沃移动通信有限公司 Gateway information use method and apparatus, terminal, and network side device
WO2024067331A1 (en) * 2022-09-28 2024-04-04 维沃移动通信有限公司 Device switching method in personal internet of things network, and communication method and device
WO2024094289A1 (en) * 2022-11-01 2024-05-10 Telefonaktiebolaget Lm Ericsson (Publ) Secure management of personal iot networks (pins)
EP4395391A1 (en) * 2022-12-28 2024-07-03 T-Mobile Innovations LLC User equipment clusters for network registration and authentication

Similar Documents

Publication Publication Date Title
US11102828B2 (en) User plane function selection for isolated network slice
US20210058784A1 (en) User equipment onboarding based on default manufacturer credentials unlicensed
WO2022159725A1 (en) Federated identity management in fifth generation (5g) system
US20230135699A1 (en) Service function chaining services in edge data network and 5g networks
US11968559B2 (en) Apparatus and method for 5G quality of service indicator management
US20210212072A1 (en) Mechanisms for transmission of multiple downlink control information
US20230354463A1 (en) State Transition of Wireless Device
US11871460B2 (en) Domain name system (DNS)-based discovery of regulatory requirements for non-3GPP inter-working function (N3IWF) selection
CN114339688A (en) Apparatus and method for authentication of a UE with an edge data network
US20240015630A1 (en) Routing Between Networks Based on Identifiers
CN115250470A (en) Arrangement in a gateway device
US20240022952A1 (en) Resource Allocation in Non-Public Network
US20230328821A1 (en) Modifying PDU Sessions In Underlay Networks
WO2022169693A1 (en) Roaming between public and non-public 5g networks
US20240129794A1 (en) Network Congestion Control
CN114641044A (en) Apparatus for use in source base station, target base station and user equipment
CN113766502A (en) Apparatus for use in a UE, SMF entity, and provisioning server
US20240154883A1 (en) Sixth generation (6g) system architecture and functions
WO2022154961A1 (en) Support for edge enabler server and edge configuration server lifecycle management
US20240236183A1 (en) Remote direct memory access (rdma) support in cellular networks
EP4239479A1 (en) Orchestration of computing services and resources for next generation systems
KR20230159413A (en) Refresh of long-term derived anchor keys and federated identity management
WO2023150721A1 (en) Sixth generation (6g) mutual transport layer security (mtls) based security architecture between user equipment (ue) and 6g network
EP4278628A1 (en) Performance measurements for network exposure function on service parameter provisioning, policy negotiation, and connection establishment
WO2023154691A1 (en) Microservice communication and computing offloading via service mesh

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22743264

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22743264

Country of ref document: EP

Kind code of ref document: A1