Securing communications for roaming user equipment (UE) using a native blockchain platform

CROSS REFERENCE TO RELATED APPLICATIONS

0001The present application is claiming priority of U.S. Provisional Patent Application Ser. No. 62/682,778, filed on Jun. 8, 2018, the contents of which are incorporated herein by reference to their entirety.

TECHNICAL FIELD

0002The present subject matter relates generally to communication networks, and more particularly, to natively integrating blockchain technologies in telecommunication networks (e.g., 4G, 5G, etc.) to provide security for roaming User Equipment (UE).

BACKGROUND

0003An ever-increasing consumer demand, improved technological advancements (e.g., hardware/software infrastructure), and industry collaboration has driven significant growth in modern telecommunication networks and continues to drive its evolution. Indeed, each iteration or “next generation” of network capabilities, e.g., represented by standards promulgated by a Third Generation Partnership Project (3GPP), interconnects more devices, improves network bandwidth, increases data-rates, and so on. For example, a transition from 3^rdGeneration (3G) networks to 4^thGeneration (4G) networks introduced new network services and connected mobile devices to third party data networks such as the Internet. More recently, a transition is underway from existing 4G networks to new 5G networks, which includes a new service-oriented architecture for provisioning network services/resources in a dynamic, scalable, and customizable fashion (e.g., micro-services, network functions virtualization (NFV), etc.). This service-oriented architecture, which employs network slices, creates new opportunities to develop scalable roaming security mechanisms in the context of roaming registration and/or roaming session management in order to natively support virtual, stateless, statistic, and dynamically mobile workloads and improve overall UE mobility in 5G networks.

BRIEF DESCRIPTION OF THE DRAWINGS

0004The embodiments herein may be better understood by referring to the following description in conjunction with the accompanying drawings in which like reference numerals indicate identical or functionally similar elements. Understanding that these drawings depict only exemplary embodiments of the disclosure and are not therefore to be considered to be limiting of its scope, the principles herein are described and explained with additional specificity and detail through the use of the accompanying drawings in which:

0005<figref idref="DRAWINGS">FIG. 1</figref> illustrates a schematic block diagram of exemplary telecommunication networks, including a 3G network, a 4G network, and a 5G network;

0006<figref idref="DRAWINGS">FIG. 2</figref> illustrates a schematic block diagram of an exemplary network device, such as a Network Function (NF) entity/module, according to one or more embodiments of this disclosure;

0007<figref idref="DRAWINGS">FIG. 3A</figref> illustrates schematic block diagram of a roaming architecture with a local breakout scenario for a service based interface representation of a Service Based Architecture (SBA);

0008<figref idref="DRAWINGS">FIG. 3B</figref> illustrates a schematic block diagram of a reference point representation of the roaming architecture shown in <figref idref="DRAWINGS">FIG. 3A</figref>, according to one embodiment of this disclosure;

0009<figref idref="DRAWINGS">FIG. 3C</figref> illustrates a schematic block diagram of another reference point representation of the roaming architecture shown in <figref idref="DRAWINGS">FIG. 3A</figref>;

0010<figref idref="DRAWINGS">FIG. 4A</figref> illustrates a schematic signalling diagram, showing callflows for a blockchain authentication procedure where User Equipment (UE) performs attach procedures, an Access and Mobility Management Function (AMF) entity invokes an Authentication Server Function (AUSF) entity to communicate with a Blockchain Authentication Function (BAF) entity;

0011<figref idref="DRAWINGS">FIG. 4B</figref> illustrates a schematic signalling diagram, showing callflows for a blockchain authentication procedure where the AMF entity is in direct communication with the BAF entity;

0012<figref idref="DRAWINGS">FIG. 5A</figref> illustrates a schematic signalling diagram, showing callflows for an out-of-band blockchain session establishment procedure;

0013<figref idref="DRAWINGS">FIG. 5B</figref> illustrates a schematic signalling diagram, showing callflows for an in-band blockchain session establishment procedure; and

0014<figref idref="DRAWINGS">FIG. 6</figref> illustrates an example simplified procedure for registering User Equipment (UE) in a communication network, in accordance with one or more embodiments of the blockchain registration procedure.

DESCRIPTION OF EXAMPLE EMBODIMENTS

0015Overview

0016This disclosure describes techniques for registering User Equipment (UE) in a telecommunication network (e.g., 4G/5G networks, etc.) using a natively integrated blockchain platform. In particular, the techniques can support complimentary or substitute blockchain authentication procedures for any User Equipment (UE) attaching to a 5G network. For example, according to one or more embodiments of this disclosure, a network function (NF) entity in a communication network receives authentication data associated with a UE, determines the UE supports a blockchain authentication procedure (e.g., based on the authentication data), and further exchanges authentication messages with a Blockchain Roaming Broker entity over a blockchain network interface. The NF entity can further receive a blockchain authentication confirmation from the BRB entity, and register the UE based on the blockchain authentication confirmation. In some embodiments, the NF entity can include an Access and Mobility Management Function (AMF) entity and/or an Authentication Server Function (AUSF) entity. Further the BRB entity may act as an agent or a gateway to a Blockchain Authentication Function (BAF) entity. Notably, the AMF entity may communicate directly with the BRB entity over the blockchain network interface and/or the AMF entity can invoke the AUSF entity to perform the authentication procedure and communicate with the BRB entity over another blockchain network interface.

0017In other embodiments, this disclosure also describes techniques for managing data sessions (e.g., establishing, hand-over, modify, etc.) for User Equipment (UE) in a telecommunication network (e.g., 4G/5G networks, etc.) using the natively integrated blockchain platform. For example, a network function (NF) entity in a communication network receives session request data associated with a User Equipment (UE), which includes blockchain authentication data. The NF entity selects a Blockchain Authentication Function (BAF) entity based on the session request data, and exchanges at least a portion of the blockchain authentication data with the BAF entity over a blockchain network interface. The NF entity further receives authentication confirmation data from the BAF entity over the blockchain network interface, and establishes a data session associated with the UE based on the authentication confirmation data.

0018Description

0019Various embodiments of the disclosure are discussed in detail below. While specific implementations are described in detail, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used without departing from the spirit and scope of the disclosure.

0020As provided herein, this disclosure relates to communication networks (e.g., telecommunication networks), which include a number of network devices/modules/entities or “Network Function(s)” (NF(s)), as is appreciated by those skilled in the art. For sake of clarity, the NFs described herein are based on NFs specified by existing Technical Specifications such as the 3GPP TS 23.501, TS 23.502, TS 24.501, TS 29.509, TS 29.518, TS 33.301, TS 33.501, each of which is incorporated herein by reference to its entirety. Moreover, while some operations and functionality may be described and/or attributed to a particular NF, it is appreciated that such operations are not intended to be limited to the particular NF, but may be performed by other NFs as appropriate, particularly in view of the ongoing development and evolving nature of telecommunication networks.

0021A communication network is a geographically distributed collection of nodes interconnected by communication links and segments for transporting data between end nodes, such as mobile devices, computers, personal computing devices (and so on), and other devices, such as network entities, sensors, etc. Many types of networks are available, ranging from local area networks (LANs) to wide area networks (WANs). LANs typically connect these nodes over dedicated private communications links located in the same general physical location, such as a building or campus. WANs, on the other hand, typically connect geographically dispersed nodes over long-distance communications links, such as common carrier telephone lines, optical lightpaths, synchronous optical networks (SONET), synchronous digital hierarchy (SDH) links, etc. Some communication networks can include telecommunication networks, which transport data between end nodes, such as user equipment (UE), which can include mobile devices.

0022<figref idref="DRAWINGS">FIG. 1</figref> illustrates a schematic block diagram of exemplary telecommunication networks <b>100</b>, including a 3G network <b>110</b>, a 4G network <b>120</b>, and 5G network <b>130</b>. Telecommunication networks <b>100</b> include wireless network interfaces or communication links, such as air interfaces <b>140</b>, an access network <b>150</b>, which represents radio infrastructure or radio towers, and a core network <b>160</b>, which represents respective core network entities, network modules, or Network Functions (NF(s)). The wireless network interfaces or air interfaces <b>140</b> include Uu links for 3G network <b>110</b>, LTE-Uu links for 4G network <b>120</b>, and 5G-NR links for 5G network <b>130</b>. In addition, other network interfaces (e.g., Nx, Sx, Lu-x, Gx, etc.) generally interconnect certain nodes (e.g., UE and/or core network entities) with other nodes (e.g., other UE and/or core network entities) based on, for example, distance, signal strength, network topology, current operational status, location, etc. As is appreciated by those skilled in the art, the network interfaces are vehicles for exchanging data packets (e.g., traffic and/or messages) between the nodes using predefined network protocols such as known wired protocols as appropriate. In this context, a protocol consists of a set of rules defining how the nodes interact with each other.

0023Those skilled in the art will understand that any number of nodes, devices, communication links, and the like may be used, and that the view shown herein is for simplicity. In particular, the representations of telecommunication networks <b>100</b>, including respective interconnected network entities, are illustrated and described herein for purposes of discussion, not limitation, and it is appreciated that the illustrated networks can include (or exclude) any number of network entities, communication links, and the like, and can support inter-network operability and compatibility.

0024Access network <b>150</b> represents the infrastructure or radio towers, such as a Radio Access Network (RAN), for receiving and transmitting data packets between end user nodes (UE) as well as the various network entities (e.g., core network entities). Access network <b>150</b> includes NodeBs (NBs) for 3G network <b>110</b>, eNodeBs (eNBs) for 4G network <b>120</b>, and gNodeBs (gNBs) for 5G network <b>130</b>. The infrastructure for each network may support different functionality and it is appreciated that infrastructure illustrated within one network can include appropriate hardware/software to support functionality of other telecommunication networks.

0025Respective network entities that form core network <b>160</b> (within the telecommunication networks <b>100</b>) operatively connect respective RAN infrastructure (NBs, eNBs, gNBs) to third party networks such as a voice network <b>105</b> (e.g., a Public Switched Telephone Network (PSTN) network) and/or a data network <b>108</b> to create end-to-end connections. Prior to 3G (e.g., 2G, 2.5G, etc.) the third party network primarily included a voice network/PSTN <b>105</b> (e.g., a circuit switched network). From 3G onward, the third party network transitioned to include a public network (e.g., the Internet), represented by data network <b>108</b> (e.g., a packet switched network). Core network <b>160</b> and its respective network entities collectively operate to manage connections, bandwidth, and mobility for respective UE.

0026Notably, core network <b>160</b> evolved along three functional planes, including service management, session management, and mobility management. Service management for 2G and 3G networks includes operations to create an Integrated Services Digital Network (ISDN) over wireless links (e.g., Uu links). Session management for 3G and 4G networks generally include operations establish, maintain, and release network resources (e.g., data connections). In particular, in 3G network <b>110</b>, session management includes a standalone General Packet Radio Service (GPRS) network, while 4G network <b>120</b> introduced a fully integrated data only network optimized for mobile broadband (where basic telephone operations are supported as one profile). Mobility management generally includes operations that support movement of UE in a mobile network, such as system registration, location tracking and handover (e.g., often optimized reduce heavy signaling loads). For example, in the context of 4G network <b>120</b>, a Serving Gateway (SGW) and a Packet Data Gateway (PGW) support session management operations while mobility management operations (which maintains data sessions for mobile UE) are centralized within a Mobility Management Entity (MME).

00275G network <b>130</b>, as discussed in greater detail herein, introduces a new service base architecture (SBA) <b>132</b>, which generally redistributes functionality of 4G network entities into smaller service-based functions/network entities. In addition, packet routing and forwarding functions (which are performed by SGW and PGW in 4G network <b>120</b>) are realized as services rendered through a new network function/entity called the User Plane Function (UPF). In this fashion, 5G network <b>130</b> provides a modular set of services that support dynamic and scalable deployment of resources to satisfy diverse user demands.

0028<figref idref="DRAWINGS">FIG. 2</figref> illustrates a schematic block diagram of an exemplary network device or Network Function (NF) entity <b>200</b> that may be used with one or more embodiments described herein, e.g., particularly as User Equipment (UE) and/or other NFs within SBA <b>132</b> (e.g., an Access and Mobility Management Function (AMF) entity, Authentication Server Function (AUSF) entity, and so on).

0029The illustrative device <b>200</b> comprises one or more network interfaces <b>210</b>, at least one processor <b>220</b>, and a memory <b>240</b> interconnected by a system bus <b>250</b>. Network interface(s) <b>210</b> contain the mechanical, electrical, and signaling circuitry for communicating data over links (e.g., wires or wireless links) within the telecommunication networks <b>100</b> (e.g., ref. <figref idref="DRAWINGS">FIG. 1</figref>). Network interfaces <b>210</b> may be configured to transmit and/or receive data using a variety of different communication protocols, as will be understood by those skilled in the art. Notably, network interfaces <b>210</b> may include new blockchain network interfaces (e.g., “BCx”, “BCy”, and/or “BCz”) as discussed in greater detail below.

0030Memory <b>240</b> comprises a plurality of storage locations that are addressable by processor <b>220</b> for storing software programs and data structures associated with the embodiments described herein. Processor <b>220</b> may comprise necessary elements or logic adapted to execute the software programs and manipulate data structures <b>245</b>. An operating system <b>242</b>, portions of which are typically resident in memory <b>240</b> and executed by processor <b>220</b>, functionally organizes the device by, inter alia, invoking operations in support of services and/or software processes executing on the device/module. These services and/or software processes may comprise an illustrative “blockchain registration” process/service <b>244</b> as well as a “blockchain session management” process/services <b>246</b>, as described herein. Note that while processes/services <b>244</b> and <b>246</b> are shown in centralized memory <b>240</b>, some embodiments provide for these processes/services to be operated in a distributed communication network.

0031Illustratively, the techniques described herein may be performed by hardware, software, and/or firmware, such as in accordance with the illustrative blockchain registration process <b>244</b> and/or the illustrative blockchain session management process <b>246</b>, which may contain computer executable instructions executed by processor <b>220</b> to perform functions relating to UE authentication and/or UE session establishment, as described herein.

0032It will be apparent to those skilled in the art that other processor and memory types, including various computer-readable media, may be used to store and execute program instructions pertaining to the techniques described herein. Also, while the description illustrates various processes, it is expressly contemplated that various processes may be embodied as modules configured to operate in accordance with the techniques herein (e.g., according to the functionality of a similar process). Further, while the processes have been shown separately, those skilled in the art will appreciate that processes may be routines or modules within other processes. For example, processor <b>220</b> can include one or more programmable processors, e.g., microprocessors or microcontrollers, or fixed-logic processors. In the case of a programmable processor, any associated memory, e.g., memory <b>240</b>, may be any type of tangible processor readable memory, e.g., random access, read-only, etc., that is encoded with or stores instructions that can implement program modules, e.g., a module having blockchain registration process <b>244</b> and/or blockchain session management process <b>246</b> encoded thereon. Processor <b>220</b> can also include a fixed-logic processing device, such as an application specific integrated circuit (ASIC) or a digital signal processor that is configured with firmware comprised of instructions or logic that can cause the processor to perform the functions described herein. Thus, program modules may be encoded in one or more tangible computer readable storage media for execution, such as with fixed logic or programmable logic, e.g., software/computer instructions executed by a processor, and any processor may be a programmable processor, programmable digital logic, e.g., field programmable gate array, or an ASIC that comprises fixed digital logic, or a combination thereof. In general, any process logic may be embodied in a processor or computer readable medium that is encoded with instructions for execution by the processor that, when executed by the processor, are operable to cause the processor to perform the functions described herein.

0033As noted above, a transition is currently underway from existing 4G networks to new 5G networks, which includes a new service-oriented architecture (e.g., SBA <b>132</b>—<figref idref="DRAWINGS">FIG. 1</figref>). Traditional processes employed by 3G and 4G networks to provision network resources, ensure appropriate levels of security, and support UE roaming and mobility (e.g., registration, session establishment, session maintenance, and so on) were developed and optimized based on then-existing voice network (e.g., circuit-switched) infrastructure and/or conventional data network (e.g., packet switched) infrastructure. For example, UE roaming in existing mobile network infrastructures is typically based on statically configured security parameters, e.g., authentication using Open Mobile Alliance (OMA) Device Management (DM) signaling, Non-Access-Stratum (NAS) protocols, key exchanges using public/private keys, statically configured security roles, and so on. In addition, existing service providers typically implement their own security mechanisms, which in turn, results in different security requirements across multiple providers further complicating inter-operability, roaming, and network resource sharing.

0034The new service based infrastructure for 5G networks provisions network services/resources in a dynamic, scalable, and customizable fashion using network slices, micro-services, network functions virtualization (NFV), and so on. In the context of a network slice, each network slice can include an isolated set of programmable resources that may implement individual network functions and/or application services through software programs within a respective network slice, without interfering with other functions and services on coexisting network slices. The new service based infrastructure, including the granular network slice approach, raises new challenges for providing comprehensive security mechanisms at multiple levels and across domains.

0035As provided herein, this disclosure describes a natively integrated blockchain security infrastructure that uses a federated, sponsored, and/or authorized blockchain enterprise platform to support scalable roaming security mechanisms in the context of roaming UE registration and/or roaming UE session management. In particular, this blockchain enterprise platform provides a distributed trust mechanism that establishes a resilient level of security for workload instantiation or resource boot as well as workload attestation after boot. This resilient level of security inherently relies upon the distributed nature of blockchain technologies.

0036Blockchain technologies generally facilitate transparent, verifiable, and secure digital asset transactions with proof of rights and ownership. For example, blockchain technologies generally employ distributed ledger technology (DLT) with built-in cryptography to enable open and trusted exchanges over the internet without requiring central servers and/or independent trusted authorities. Although blockchain technologies can be non-natively employed within existing telecommunication networks, mobile network operators and/or mobile network entities are generally unaware of blockchain transactions because such blockchain transactions generally only occur after a mobile session is established (e.g., using overlay messages), which in turn, inhibits blockchain technology integration and participation by mobile service providers.

0037Accordingly, as described in greater detail herein, the blockchain platform of this disclosure is natively integrated with the service based architecture (SBA) of the 5G network through new blockchain network interfaces such as BCx and Bcy. The blockchain platform includes a network of blockchain service providers as well as a blockchain roaming agent, which is operable to provide roaming UE security within networks and between different network providers. As described in greater detail herein, these new roaming security mechanisms include roaming blockchain registration as well as roaming blockchain session management for UE. For example, the blockchain roaming agent may employ the roaming security mechanisms to support device registration processes within a mobile network, device registration in the context of a roaming network (e.g., when UE is outside of its local/home network and attempts to connect to a roaming/visiting network), and device session management processes to improve overall UE mobility in 5G networks.

0038Referring again to the figures, <figref idref="DRAWINGS">FIG. 3A</figref> illustrates a schematic block diagram <b>301</b>, showing a blockchain platform natively integrated with a Service Based Architecture (SBA) <b>132</b> for an exemplary 5G network (e.g., 5G network <b>130</b>). <figref idref="DRAWINGS">FIGS. 3B and 3C</figref> illustrates schematic block diagram <b>302</b> and <b>303</b>, respectively, showing example embodiments of reference point architectures for the blockchain platform of <figref idref="DRAWINGS">FIG. 3A</figref>. Collectively, <figref idref="DRAWINGS">FIGS. 3A-3C</figref> show a native blockchain platform, which includes an enterprise blockchain network <b>304</b> of interconnected blockchain service providers (SPs) or Blockchain Authentication Function (BAF) entities <b>305</b><i>a</i>-<b>305</b><i>n </i>(e.g., distributed ledger technology (DLT) entities, etc.), and a Blockchain Roaming Broker (BRB) entity <b>306</b>, which acts as a software defined agent accessible to various network entities of SBA <b>132</b> (e.g., over blockchain network interfaces BCx, BCy, and BCz, etc.)

0039Notably, the illustrated blockchain network interfaces BCx, BCy, and BCz may be represented by network interfaces <b>210</b> for device/entity <b>200</b>, discussed above. Further, these blockchain network interfaces represent communication links that facilitate exchanging messages or data packets between BAF(s), BRB <b>306</b>, and core network entities (e.g., NFs) that form SBA <b>132</b>. For example, BCx can facilitate exchanging messages related to policy request, authorization, network usage, lawful intercept, accounting, and the like. BCy can facilitate exchanging messages related to secondary authentication, authorization, resource sharing, lawful intercept, network slicing, etc. BCz can facilitate exchanging messages related to standalone Authentication public key pre-set, authorization, Distributed Ledger Technology query/set, etc.

0040Blockchain network <b>304</b> helps establish trust by way of immutable distributed records, which are accessible to BAFs <b>305</b> as well as BRB <b>306</b>. In operation, NFs of SBA <b>132</b> can access the immutable distributed records of blockchain network <b>304</b> to authenticate, authorize, or otherwise provide roaming security for UE registration processes and session management processes. In this fashion, blockchain network <b>304</b> can create specific trust boundaries across multiple service providers using distributed blockchain ledgers, which can be leveraged when sharing network resources or providing access to network functions (NFs) such as Access and Mobility Management Function (AMF), Session Management Function (SMF), Network Repository Function (NRF), and so on, as discussed in greater detail herein. Blockchain network <b>304</b> may represent an open source blockchain network, a public blockchain network, and/or a private blockchain network, and may include distributed ledger technologies such as hyperledger Sawtooth, and the like.

0041Referring again to <figref idref="DRAWINGS">FIG. 3A</figref>, schematic block diagram <b>301</b> illustrates a roaming architecture with a local breakout scenario for a service based interface representation of SBA <b>132</b>. Roaming generally refers to situations where the UE from one network (e.g., a home network) operates in another network (e.g., a visiting network). Typical roaming networks can include, for example, an Internet Protocol (IP) Packet eXchange (IPX) Network for 4G and 5G technologies, which is an inter-Service Provider IP backbone that includes interconnected networks of IPX Providers. For 2G and 3G technologies General Packet Radio Service (GPRS) Roaming eXchange (GRX) is used to provide roaming capabilities. Both GRX and IPX networks operably exchange IP based traffic between customers of separate mobile and fixed operators as well as other types of service provider (such as ISP), via IP based Network-to-Network Interface. Specifications for roaming networks can be defined by GSMA guidelines such as IR.34 guidelines for IPX provider networks, the contents of which are incorporated herein by reference to its entirety. As shown in <figref idref="DRAWINGS">FIG. 3A</figref> (and discussed in greater detail herein), schematic block diagram <b>301</b> includes a blockchain roaming broker (BRB) that facilitates roaming across 3G, 4G and 5G mobile technologies using secured Distributed Ledger Technologies (DLT).

0042The roaming architecture shown in schematic block diagram <b>301</b> includes a Visited Public Land Mobile Network (VPLMN) and a Home Public Land Mobile Network (HPLMN). A Public Land Mobile Network (PLMN) is a network established and operated by a carrier for providing mobile communication services to its subscribers. Generally, domestic subscribers for a carrier use roaming if to receive services from abroad. A HPLMN refers to the subscriber's home network (e.g., domestic carrier) while VPLMN refers to the subscriber's abroad network (where the UE may be registered while roaming). While <figref idref="DRAWINGS">FIG. 3A</figref> illustrates the roaming architecture with the local breakout scenario, it is appreciated other roaming architectures may be employed (e.g., home routing, etc.). Further, as shown here, some network entities such as the Session Management Function (SMF) and the User Plane Function(s) (UPF(s)) involved in a PDU session are under the control of the VPLMN.

0043An IPX network (not shown) may provide IP-based interoperability between the VPLMN and the HPLMN. However, such IPX network often increases costs associated with roaming due, in part, to the numerous protocols and complex IPX messaging. In addition, security requirements for a home network may be different than those of a visiting network. As discussed herein, this disclosure provides a natively integrated blockchain enterprise platform that supports blockchain registration processes and blockchain session management processes. This natively integrated blockchain enterprise platform avoids often expensive and complex signaling and message exchanges between VPLMNs and HPLMNs (and over IPX networks) and can include a Blockchain Roaming Broker (BRB) entity (e.g., BRB <b>306</b>), which operably establishes trust and secures communications between UE and a mobile network (e.g., NFs that form SBA <b>132</b>) using a distributed immutable record.

0044BRB <b>306</b> can be implemented for both domestic and international roaming and can provide instant service authorizations and network usages for roaming UE that support the blockchain registration processes and/or the blockchain session management processes. For example, BRB <b>306</b> may be accessible to network entities that form SBA <b>132</b> and reside in VPLMN and/or HPLMN.

0045The network entities that form SBA <b>132</b> include, for example, AMF <b>320</b>, SMF <b>325</b>, Network Slice Selection Function (NSSF) <b>330</b>, Network Exposure Function (NEF) <b>335</b><i>v</i>|<b>335</b><i>h</i>, Network Repository Function (NRF) <b>340</b><i>v</i>|<b>340</b><i>h</i>, Policy Control Function (PCF) <b>345</b><i>v</i>|<b>345</b><i>h</i>, and Application Function (AF) <b>350</b>. These network entities can be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., a cloud infrastructure, as is appreciated by those skilled in the art.

0046In general, UE <b>308</b> connects to RAN/Access Network (AN) <b>310</b> as well as AMF <b>320</b>. Here, the RAN can include a base station while the AN can include a base station supporting non-3GPP access, e.g., Wi-Fi access. AMF <b>320</b> provides UE-based authentication, authorization, mobility management, etc. SMF <b>325</b> is responsible for session management, IP address allocation to UE(s), and traffic management/selection of a User Plane Function (UPF) (e.g., UPF <b>315</b>) for proper routing/data transfer. If UE <b>308</b> has multiple sessions, different SMFs may be allocated to each session for individual management and/or different functionality per session. AF <b>350</b> generally provides information on packet flows to PCF <b>345</b><i>v</i>, which is responsible for policy control in order to support Quality of Service (QoS). Based on the information from AF <b>350</b>, PCF <b>345</b><i>v </i>determines policies about mobility and session management for proper AMF/SMF operations. AUSF <b>355</b> stores authentication data for UE <b>308</b>, and UDM <b>360</b> stores subscription data for UE <b>308</b>. Data network <b>108</b> provides Internet access or operator services. The foregoing operations (and additional functionality) for respective network entities can be found in 3GPP Technical Specification (TS) 23.501 v 15.2.0 and TS 23.502v15.2.0, which is incorporated by herein by reference to its entirety.

0047Notably, the disclosed blockchain security operations, such as those employed for roaming UE registration and/or roaming UE session management, are discussed in greater detail below, and with reference to subsequent signaling diagrams illustrated in <figref idref="DRAWINGS">FIGS. 4A, 4B, 5A, and 5B</figref>. As discussed below, such blockchain security operations involve messages exchanged over the new blockchain network interfaces BCx, BCy, and BCz, and between one or more NFs in SBA <b>132</b>, BRB <b>306</b>, and/or BAF(s) <b>305</b>.

0048<figref idref="DRAWINGS">FIG. 3B</figref> illustrates a schematic block diagram <b>302</b>, showing a reference point interface representation of SBA <b>132</b> (e.g., with a local breakout (LBO) scenario). Reference point representations help develop detailed call flows in a normative standardization, which are illustrated in <figref idref="DRAWINGS">FIGS. 4A, 4B, 5A, and 5B</figref> and described in greater detail herein. It should be noted, for sake of clarity, certain network entities (e.g., NEF <b>335</b>, NRF <b>340</b>, etc.) are not shown by schematic block diagram <b>302</b>. However, it is appreciated any of the illustrated network entities can interact with the non-illustrated entities as appropriate.

0049As illustrated, N1 carries signaling between UE <b>308</b> and AMF <b>320</b>. The reference points for connecting between (R)AN <b>310</b> and AMF <b>320</b> and between (R)AN <b>310</b> and UPF <b>315</b> are defined as N2 and N3, respectively. There is a reference point, N11, between AMF <b>320</b> and SMF <b>325</b>. In this fashion, SMF <b>325</b> may be controlled by AMF <b>320</b>. N4 is used by SMF <b>325</b> and UPF <b>315</b> so that the UPF <b>315</b> can be set using the control signal generated by the SMF <b>325</b>, and the UPF <b>315</b> can report its state to the SMF <b>325</b>. N15 and N7 are defined since PCF <b>345</b> applies policy to AMF <b>320</b> and SMF <b>325</b>, respectively. N12 is used AMF <b>320</b> to perform authentication of UE <b>308</b>. N8 and N10 provide subscription data of UE <b>308</b> from UDM <b>360</b> to AMF <b>320</b> and SMF <b>325</b>. In addition, BCy network interface interconnects AMF <b>320</b> and BRB <b>306</b> to provide alternative or supplemental authentication/registration signaling for UE <b>308</b>. Notably, in some embodiments, UE <b>308</b> may be authenticated/registered by AUSF <b>355</b> over blockchain network interface BCx. In addition, BCx network interface interconnects PCF <b>345</b> and BRB <b>306</b> for data session management, including blockchain charging events/transactions. Additional reference points are illustrated and can generally operate in accordance with 3GPP specifications, as is appreciated by those skilled in the art.

0050<figref idref="DRAWINGS">FIG. 3C</figref> illustrates a schematic block diagram <b>303</b>, showing another reference point interface representation of SBA <b>132</b>. Here, schematic block diagram <b>303</b> particularly illustrates blockchain network interfaces BCx interconnecting BRB <b>306</b> with NEF <b>335</b>, which may be invoked by SMF <b>325</b> and/or PCF <b>345</b>, as discussed in greater detail herein. In addition, in some embodiments, blockchain network interface BCx may interconnect BRB <b>306</b> with UDM <b>360</b> to provide registration information.

0051As mentioned above, <figref idref="DRAWINGS">FIGS. 3A-3C</figref> illustrate a native blockchain platform, including an enterprise blockchain network <b>304</b> of interconnected blockchain service providers (SPs) or Blockchain Authentication Function (BAF) entities <b>305</b><i>a</i>-<b>305</b><i>n </i>(e.g., distributed ledger technology (DLT) entities, etc.), and a Blockchain Roaming Broker (BRB) <b>306</b>, which acts as a software defined agent accessible to various network entities of SBA <b>132</b> (e.g., over blockchain network interfaces BCx, BCy, and BCz, etc.) In general, this native blockchain platform can provide an additional and/or alternative blockchain security mechanisms natively employed as part of UE registration processes as well as UE data session management processes (e.g., PDN/PDU sessions, etc.) Notably, the blockchain security mechanisms may be represented by blockchain registration process/services <b>244</b>, and/or blockchain session management process/services <b>246</b> (ref. <figref idref="DRAWINGS">FIG. 2</figref>).

0052The blockchain registration process generally includes operations to register and attach the UE to the core network and to encrypt and protect traffic between the UE and core network entities (e.g., SBA <b>132</b>). For example, the registration operations can include exchanging authentication messages between one or more core NFs of SBA <b>132</b> and BRB <b>306</b>, which is exposed to the core NFs over new blockchain network interfaces (e.g., BCy and/or BCz). In some embodiments, the core NFs can further invoke NEF <b>335</b> to transparently forward the authentication messages to/from BRB <b>306</b>. BRB <b>306</b> further communicates with a corresponding BAF <b>305</b> (e.g., based on authentication information such as UE account credentials with the BAF). The corresponding BAF <b>305</b>, in turn, compares the UE account credentials against UE credentials stored on a blockchain or distributed ledger. As is appreciated by those skilled in the art, the BAF returns authentication confirmation messages to BRB <b>306</b> if the UE credentials match the UE credentials stored on the blockchain or distributed ledger. BRB <b>306</b> further provides appropriate confirmation messages to the core network NFs to complete registration procedure and attach UE to the core network.

0053The blockchain session management process generally includes operations to establish sessions (e.g., PDU sessions/PDN sessions) with UE <b>308</b> in order to allocate session resources to relevant network slices, permit data transmission between UE <b>308</b> and data network <b>108</b>, ensure appropriate Quality of Service (QoS) connectivity, satisfy Service Level Agreements (SLA(s)), and so on. Notably, the blockchain session management processes may include authentication/authorization operations, however it is appreciated such operations relate to session management and may be separate from the blockchain registration process for attaching the UE to the network. Similar to the blockchain registration process discussed above, the blockchain session management operations include exchanging messages between one or more core NFs of SBA <b>132</b> (including NEF <b>335</b> (if invoked)) and BRB entity <b>306</b> over a new blockchain network interface (e.g., BCy and/or BCz). BRB <b>306</b> further communicates with a corresponding BAF (e.g., based on the session management authentication information and/or the registration authentication information) to authenticate or authorize UE <b>308</b> for purposes of session establishment, and pass on confirmation messages back to appropriate core network entities upon successful authentication/authorization.

0054In proper context, and with reference to <figref idref="DRAWINGS">FIGS. 3A, 3B</figref>, and/or <b>3</b>C, various network entities cooperate to perform initial registration and attachment processes for UE <b>308</b>. In particular, RAN/Access Network (AN) <b>310</b> broadcasts system information (e.g., PLMN-IDs) to various UE(s), including UE <b>308</b>. UE <b>308</b> receives the PLMN-ID from RAN/Access Network (AN) <b>310</b> and, during its initial registration, UE <b>308</b> indicates support for a complimentary (and/or substitute) blockchain procedures (e.g., the blockchain registration procedure and/or the blockchain session management procedure). For example, UE <b>308</b> can indicate support for these blockchain procedures in a radio layer message (e.g., a Radio Resource Control (RRC) message) sent to RAN/Access Network (AN) <b>310</b>.

0055RAN/Access Network (AN) <b>310</b> receives the RRC messages from UE <b>308</b> and selects an appropriate AMF <b>320</b> (which supports the blockchain procedures) and/or redirects the RRC messages to a new AMF as appropriate. Here, RAN/AN <b>310</b> can determine the RRC message from UE <b>308</b> include an indication for the disclosed blockchain procedures (e.g., in an access category) and selects AMF <b>320</b> and/or redirects to a new AMF based on the AMF blockchain capabilities.

0056In some embodiments, AMF <b>320</b> receives an indication to perform the blockchain registration procedure from Non-Access Stratum (NAS) messages sent directly from UE <b>308</b> (e.g., over network interface N1) to AMF <b>320</b>. In this fashion, the NAS messages can indicate UE <b>308</b> supports/request the blockchain authentication procedure, e.g., in payload data such as registration type in the NAS message, and/or in follow-on request data.

0057AMF <b>320</b> further exchanges blockchain authentication messages with BRB <b>306</b>, over blockchain network interfaces BCx and/or BCy. In some embodiments, AMF <b>320</b> may send authentication messages to invoke/request that AUSF <b>355</b> perform blockchain registration operations, which causes AUSF <b>355</b> to authenticate UE <b>308</b> with BRB <b>306</b> over blockchain network interface BCx (e.g., ref. <figref idref="DRAWINGS">FIG. 4A</figref>). In other embodiments, AMF <b>320</b> can directly authenticate UE <b>308</b> with BRB <b>306</b> over blockchain network interface BCy, using for example, REST Application Program Interface (API) messages (e.g., ref. <figref idref="DRAWINGS">FIG. 4B</figref>). BRB <b>306</b> further authenticates the blockchain credentials for UE <b>308</b> with a corresponding BAF <b>305</b>, as mentioned above. For example, the BAF <b>305</b> receives the UE credentials, compares the UE credentials against stored UE credentials (e.g., stored on a blockchain or distributed ledger) and sends appropriate confirmation messages when the UE credentials match the stored UE credentials.

0058Notably, AMF <b>320</b> and/or AUSF <b>355</b> can also perform conventional registration processes in addition to the above discussed blockchain authentication operations, depending on service provider or mobile network operator security/integrity policies, as is appreciated by those skilled in the art—e.g., generating/creating encryption keys (e.g., anchor keys), sending authentication requests to AUSF <b>355</b>, selecting UDM <b>360</b>, retrieving vectors, e.g., credentials and/or encryption keys, from UDM <b>360</b>, and so on. In this fashion, the blockchain authentication procedure can complement (or augment) existing authentication processes (e.g., 5G Extensible Authentication Protocol (EAP)—Authentication and Key Agreement (AKA) procedures defined by 3GPP TS 33.301, etc.) to serve as an enhanced or secondary form of security. In other embodiments, however, the blockchain authentication procedure can replace existing authentication processes (e.g., if existing authentication processes fail, etc.)

0059These and other blockchain enhanced registration features are described in greater detail with respect to the schematic signaling diagrams shown in <figref idref="DRAWINGS">FIGS. 4A and 4B</figref>, below.

0060Still referring to <figref idref="DRAWINGS">FIGS. 3A, 3B</figref>, and/or <b>3</b>C, various network entities or NFs also cooperate to manage sessions for UE <b>308</b> (e.g., establish sessions, handover sessions, modify sessions, etc.). Sessions are typically managed as part of a connectivity service (e.g., PDU Connectivity Service), which defines rules for exchanging data packets (e.g., Protocol Data Units (PDUs)) between the UE (e.g., UE <b>308</b>) and a data network (e.g., data network <b>108</b>) based on session-specific Quality of Service (QoS) parameters. This connectivity service can include multiple PDU sessions, which are logical associations created between the 5G core network entities (e.g., SBA <b>132</b>) and UE <b>308</b> to handle data packet exchanges. In the context of a 5G network, session management is flexible, scalable, and accommodates various service continuity modes (e.g., “make before break” options, relocation of core network functions, etc.) while maintaining seamless end-user services. The session management also supports concurrent local and central access to a data network and multi-access edge computing where an application at an edge data centre can influence traffic routing to improve its performance.

0061While session management is illustrated and described herein in the context of 5G networks (e.g., PDU sessions), it is appreciated such session management and related operations can readily apply to 4G networks (e.g., PDN sessions, etc.) For example, as is appreciated by those skilled in the art, 4G networks create sessions using default data bearers (e.g., 4G networks), while the 5G networks establish a PDU session as-needed or on demand, independent of UE attachment procedures. Further, UE(s) can establish multiple PDU sessions to the same data network (or to different data networks) over a single or multiple access networks (e.g., 3GPP networks, non-3GPP networks, etc.) where each PDU session is associated with network slice—e.g., one S-NSSAI and one Data Network Name (DNN). Notably, the PDU sessions can include various session types (e.g., IPv4, IPv6, Ethernet, unstructured, etc.)

0062In operation, UE <b>308</b> initiates session establishment by sending a PDU session request data to AMF <b>320</b> (e.g., as part of a PDU Session Establishment Request message). Notably, when UE <b>308</b> attaches to the core network (e.g., SBA <b>132</b>), UE <b>308</b> exchanges mobility management messages and session management messages with AMF <b>320</b> (e.g., over an NG1 NAS network interface). Session management messages can be transmitted with the mobility management message supported by the NAS routing capability within AMF <b>320</b>. Although AMF <b>320</b> is involved in sending session management messages, processing mobility messages and session management messages typically occurs in AMF <b>320</b> and SMF <b>325</b>, respectively.

0063AMF <b>320</b> receives the PDU session request and discovers/selects an appropriate SMF (e.g., SMF <b>325</b>) based on parameters included in the initial PDU session request from UE <b>308</b>, such as session management service identification data, Single Network Slice Selection Assistance Information (S-NSSAI) data, Data Network Name (DNN) data, UE subscriptions, local operator policies, blockchain authentication data/capabilities, etc.). Although AMF <b>320</b> may not understand the full context of the session management messages, it can still determine/select an appropriate SMF for a new PDU session based on the above-mentioned parameters.

0064Here, AMF <b>320</b> selects SMF <b>325</b> and establishes a PDU session, which allocates PDU resources for a relevant network slice and permits data transmission/data packet exchanges between UE <b>308</b> and data network <b>108</b>. In addition, AMF <b>320</b> also ensures that NAS signaling associated with this PDU session is handled by the same SMF (SMF <b>325</b>) by assigning a PDU session identifier to the PDU session. UE <b>308</b>, in turn, uses this PDU session identifier to route messages to the correct SMF.

0065As mentioned, PDU sessions are typically managed as part of a connectivity service (e.g., PDU Connectivity Service), which defines rules for exchanging data packets (e.g., Protocol Data Units (PDUs)) between the UE (e.g., UE <b>308</b>) and a data network (e.g., data network <b>108</b>) based on session-specific Quality of Service (QoS) parameters. Subscription information for each S-NSSAI can include multiple DNNs and one default DNN. When UE <b>308</b> does not specify a DNN in a NAS Message containing PDU Session Establishment Request for a given S-NSSAI, the serving AMF determines the DNN for the requested PDU Session by selecting the default DNN for this S-NSSAI if a default DNN is present in the UE's Subscription Information; otherwise the serving AMF selects a locally configured DNN for this S-NSSAI. If the DNN provided by the UE is not supported by the network and AMF cannot select an SMF by querying NRF, the AMF may reject the NAS Message containing PDU Session Establishment Request from the UE with a cause indicating that the DNN is not supported.

0066Each PDU Session typically supports a single PDU Session type, e.g., supports the exchange of a single type of PDU requested by UE <b>308</b> at the establishment of the PDU Session. PDU Sessions are generally established upon UE request, modified upon UE <b>308</b>/SBA <b>132</b> request, and released upon UE <b>308</b>/SBA <b>132</b> request using NAS session management signaling exchanged over the N1 network interface between UE <b>308</b> and SMF <b>325</b>. Upon request from an Application Server, SBA <b>132</b> is able to trigger a specific application in UE <b>308</b>. When receiving the trigger message, UE <b>308</b> passes it to the identified application (in UE <b>308</b>). The identified application in UE <b>308</b> may establish a PDU Session to a specific DNN, in accordance with 3GPP TS 32.501, clause 4.4.5.

0067SMF <b>325</b> is responsible of checking whether UE requests are compliant with the user subscription. For this purpose, SMF <b>325</b> retrieves and requests to receive update notifications on SMF level subscription data from UDM <b>360</b>. This subscription data can incidate (e.g., per DNN and per S-NSSAI) allowed PDU Session Types and the default PDU Session Type, allowed SSC modes and the default SSC mode, QoS Information, subscribed Session-AMBR, Default 5QI and Default ARP, static IP address/prefix, subscribed User Plane Security Policy, Charging Characteristics to be associated with the PDU Session, and so on.

0068In addition, UE <b>308</b> may request to move a PDU Session between 3GPP and Non 3GPP accesses. The decision to move PDU Sessions between 3GPP access and Non 3GPP access is made on a per PDU Session basis, e.g., UE <b>308</b> may, at a given time, have some PDU Sessions using 3GPP access while other PDU Sessions are using Non 3GPP access. UE <b>308</b> typically provides a PDU session ID in a PDU Session Establishment Request message. The PDU session ID is unique per UE and represents a unique identifier assigned to a PDU Session. The PDU session ID can be stored in UDM <b>360</b> to support handover between 3GPP and non-3GPP access—e.g., when different PLMNs are used for the two accesses.

0069While many of the above discussed operations may be performed as part of conventional session management processes, this disclosure further describes blockchain session management processes where one or more network entities/NFs of SBA <b>132</b> exchange messages with BRB <b>306</b> over new blockchain interfaces (e.g., BCy and/or BCz) in order to establish a data session for UE <b>308</b>. The disclosed blockchain session management processes may complement existing session management processes similar to secondary authentication processes that use an Authentication Authorization, and Accounting (AAA) server in a data network. Here, however, the blockchain enterprise platform (e.g., BRB <b>306</b>, enterprise blockchain network <b>304</b>, and BAF(s) <b>305</b><i>a</i>-<i>n</i>) is natively integrated with and directly exposed to SBA <b>132</b>. It is also appreciated that the blockchain session management processes, in other embodiments, may replace existing session management processes.

0070With respect to the blockchain session management processes, SMF <b>325</b> receives session request data associated with UE <b>308</b>. This session request data may be included as part of a PDU Session Establishment Request message, which may comprise the above-mentioned parameters such as the blockchain authentication data. In some embodiments, AMF <b>320</b> initially selects SMF <b>325</b> based on the session request data and further forwards the session request data to SMF <b>325</b> (once selected). SMF <b>325</b> selects BRB <b>306</b> based on the session request data, and further exchanges at least a portion of the blockchain authentication data (e.g., blockchain authentication credentials associated with UE <b>308</b>) with BAF <b>305</b> over a blockchain network interface (e.g., BCx and/or BCy, where SMF <b>325</b> may route messages through AMF <b>320</b>, etc.)

0071In some embodiments, SMF <b>325</b> may further select an NEF (e.g., NEF <b>335</b>—shown in a dashed box in <figref idref="DRAWINGS">FIG. 3C</figref>) to act as an Application Program Interface (API) gateway between SMF <b>325</b> and BRB <b>306</b>. In these embodiments, SMF <b>325</b> exchanges authentication data with NEF <b>335</b>, which in turn exchanges messages with BAF <b>305</b> over the blockchain network interface BCx. In other embodiments, SMF <b>325</b> may directly communicate with BRB <b>306</b> over the blockchain network interface BCx.

0072SMF <b>325</b> receives authentication confirmation data from BAF <b>305</b> over the blockchain network interface BCx and establishes a session associated with the UE based on the authentication data.

0073In some embodiments, SBA <b>132</b> may apply a restricted access policy to the session while one or more NFs perform a blockchain credit check/charging event process. In particular, SMF <b>325</b> can communicate with PCF <b>345</b> to obtain payment credits (e.g., blockchain tokens, etc.) in order to ensure the services to be provided to UE <b>308</b> align with its creditworthiness. In turn, PCF <b>345</b> can solicit blockchain payment credits from BRB <b>306</b> (e.g., either directly and/or indirectly through NEF <b>335</b>) over the blockchain network interface BCx. PCF <b>345</b> and/or SMF <b>325</b> can determine that the blockchain payment credits satisfy a payment criteria for one or more network services (e.g., as part of the blockchain charging event), and further remove, modify, and/or update the restricted access policy for the data session.

0074These and other blockchain enhanced session management features are described in greater detail with respect to the schematic signaling diagrams shown in <figref idref="DRAWINGS">FIGS. 5A and 5B</figref>, below.

0075Blockchain Registration Process

0076<figref idref="DRAWINGS">FIGS. 4A and 4B</figref> illustrate respective schematic signaling diagrams <b>401</b> and <b>402</b> for the disclosed a blockchain registration procedure, where AMF <b>320</b> invokes AUSF <b>355</b> in diagram <b>401</b>, and AMF <b>320</b> directly authenticates UE <b>308</b> with BRB <b>306</b> in diagram <b>402</b>. In general, UEs register with the network in order to receive network services, enable mobility tracking, and support mobility/reachability. Notably, the call flow for the blockchain registration procedures can vary based on initial registrations, mobility registration updates, periodic registration updates, and so on. While signaling diagrams <b>401</b> and <b>402</b> illustrate an initial registration procedure in accordance with embodiments of the disclosed blockchain registration procedure, it is appreciated the call flows may be modified based the type of UE registration.

0077Referring to <figref idref="DRAWINGS">FIG. 4A</figref>, schematic signaling diagram <b>401</b> begins at step <b>403</b>, where UE <b>308</b> sends a registration request message to RAN/AN <b>310</b>. In one embodiment, the registration request message can indicate UE <b>308</b> supports a blockchain registration procedure using, for example, data fields such as access categories/access identities for existing registration messages (e.g., in accordance with access identities/access categories and RRC establishment clauses specified by 3GPP TS 24.501, table 4.5.6.1 (below)).

0078<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="84pt" align="left" /><colspec colname="3" colwidth="77pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row><row><entry /><entry>Access </entry><entry /><entry>RRC establishment</entry></row><row><entry /><entry>identities</entry><entry>Access categories</entry><entry>cause is set to</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>0</entry><entry>0 (=MT_acc)</entry><entry>MT access</entry></row><row><entry /><entry /><entry>1 (=delay tolerant)</entry><entry>FFS</entry></row><row><entry /><entry /><entry>2 (=emergency)</entry><entry>Emergency call</entry></row><row><entry /><entry /><entry>3 (=MO_sig)</entry><entry>MO signaling</entry></row><row><entry /><entry /><entry>4 (=MO MMTel voice)</entry><entry>MO voice call</entry></row><row><entry /><entry /><entry>5 (=MO MMTel video)</entry><entry>FFS</entry></row><row><entry /><entry /><entry>6 (=MO SMS and</entry><entry>FFS</entry></row><row><entry /><entry /><entry>SMSoIP)</entry><entry /></row><row><entry /><entry /><entry>7 (=MO_data)</entry><entry>MO data</entry></row><row><entry /><entry>1</entry><entry>Any category</entry><entry>“High priority access”</entry></row><row><entry /><entry>2</entry><entry>Any category</entry><entry>“High priority access”</entry></row><row><entry /><entry>11, 15</entry><entry>Any category</entry><entry>“High priority access”</entry></row><row><entry /><entry>12, 13, 14,</entry><entry>Any category</entry><entry>“High priority access”</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row><row><entry /><entry namest="offset" nameend="3" align="left" id="FOO-00001">NOTE:</entry></row><row><entry /><entry namest="offset" nameend="3" align="left" id="FOO-00002">See subclause 4.5.2, table 4.5.2.1 for use of the access identities of 0, 1, 2, and 11-15.</entry></row></tbody></tgroup></table></tables>

0079RAN/AN <b>310</b> further selects an AMF—here, AMF <b>320</b>—based on the registration message. For example, RAN/AN <b>310</b> determines the registration request message indicates UE <b>308</b> supports the blockchain authentication procedure, and can select an appropriate AMF that likewise supports such procedure. Alternatively, RAN/AN <b>310</b> can reject the blockchain authentication request, which causes the UE to revert to existing 3GPP behaviour.

0080At step <b>404</b>, RAN/AN <b>310</b> sends a registration request message to AMF <b>320</b>. As mentioned, these registration request messages (and corresponding call flows) may generally follow existing registration procedures such as those specified in 3GPP TS 23.502 (e.g., 4.2.2.2). However, in accordance with the disclosed blockchain authentication procedure, the registration request message may further include a registration type information element (e.g., 5GS registration type information element, defined in 3GPP TS 24.501, 9.8.3.7) that indicates guest access with the additional blockchain mechanisms (e.g., the blockchain authentication procedure).

0081For example, the 5GS registration type information element is provided below:

0082<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>9.8.3.7.1: 5GS registration type information element</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="9"><colspec colname="1" colwidth="14pt" align="center" /><colspec colname="2" colwidth="21pt" align="center" /><colspec colname="3" colwidth="14pt" align="center" /><colspec colname="4" colwidth="21pt" align="center" /><colspec colname="5" colwidth="28pt" align="center" /><colspec colname="6" colwidth="28pt" align="center" /><colspec colname="7" colwidth="21pt" align="center" /><colspec colname="8" colwidth="28pt" align="center" /><colspec colname="9" colwidth="42pt" align="center" /><tbody valign="top"><row><entry>8</entry><entry>7</entry><entry>6</entry><entry>5</entry><entry>4</entry><entry>3</entry><entry>2</entry><entry>1</entry><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="70pt" align="center" /><colspec colname="2" colwidth="28pt" align="center" /><colspec colname="3" colwidth="77pt" align="center" /><colspec colname="4" colwidth="42pt" align="center" /><tbody valign="top"><row><entry>5GS registration </entry><entry>FOR</entry><entry>5GS registration </entry><entry>octet 1</entry></row><row><entry>type IEI</entry><entry /><entry>type value</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0083<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>9.8.3.7.1: 5GS registration type infonnation element</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>5GS registration type value (octet 1)</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="42pt" align="center" /><colspec colname="2" colwidth="14pt" align="center" /><colspec colname="3" colwidth="42pt" align="center" /><colspec colname="4" colwidth="119pt" align="left" /><tbody valign="top"><row><entry>Bits</entry><entry /><entry /><entry /></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry>3</entry><entry>2</entry><entry>1</entry><entry /></row><row><entry>0</entry><entry>0</entry><entry>1</entry><entry>initial registration</entry></row><row><entry>0</entry><entry>1</entry><entry>0</entry><entry>mobility registration updating</entry></row><row><entry>0</entry><entry>1</entry><entry>1</entry><entry>periodic registration updating</entry></row><row><entry>1</entry><entry>1</entry><entry>0</entry><entry>emergency registration </entry></row><row><entry>1</entry><entry>1</entry><entry>1</entry><entry>reserved</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>All other values are unused and shall be interpreted </entry></row><row><entry>as “initial registration”, if received by the network.</entry></row><row><entry>Follow-On Request bit (FOR) (octet 1)</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="center" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry>Bit</entry><entry /></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>4</entry><entry /></row><row><entry>0</entry><entry>No follow-on request pending</entry></row><row><entry>1</entry><entry>Follow-on request pending</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0084In one embodiment, the 5GS registration type information element can enable a follow-on attribute and/or set the follow-on-request bit, which can indicate support or information corresponding to the blockchain authentication procedure. In another embodiment, the 5GS registration type information element can be modified to include a registration type that indicates the guest authenticating mechanism (e.g., the blockchain authentication procedure).

0085In some embodiments, the blockchain registration procedure, whether indicated in the registration request message with the follow-on request bit or the modified registration type, can include a non-3GPP authentication procedure piggy backed over a Non-Access Stratum (NAS) message. For example, the blockchain authentication procedure could be carried in a transparent container payload of the NAS protocol where the authentication type can be indicated in a NAS payload. Notably, in accordance with network service provider or operator policy/requirements, AMF <b>320</b> may first perform standard EAP-AKA procedures (e.g., as defined by 3GPP TS 33.301, 6.1.2 and 6.1.3), and if successful, AMF <b>320</b> may further perform the blockchain authentication procedure as a complimentary or supplemental process. However, as mentioned above, in some instances, AMF <b>320</b> may perform the blockchain authentication procedure and register/attach UE <b>308</b> to the network even if the standard EAP-AKA procedures fail (depending on policy/requirements).

0086Signaling diagram <b>401</b> continues to steps <b>406</b> and <b>408</b> where UE <b>308</b> and AMF <b>320</b> exchange identity request/response messages. Here, AMF <b>320</b> initiates a UE identity request at step <b>406</b> during an initial registration, e.g., when AMF <b>320</b> is new to UE <b>308</b>, and/or when AMF <b>320</b> was not provided Subscriber Concealed Identifier (SUCI) information from prior AMF(s) (e.g., in accordance with 3GPP TS 23.502 procedures). As shown, AMF <b>320</b> particularly initiates authentication with UE <b>308</b> by sending an identity request message at step <b>406</b> and, in response, UE <b>308</b> generates and transmits, a corresponding identity response (e.g., with a SUCI or privacy preserving identifier containing a concealed subscriber permanent identifier (SUPI)) in step <b>408</b>.

0087In some embodiments, UE <b>308</b> returns additional parameters at step <b>408</b> to indicate support for the blockchain registration procedure (e.g., in addition to or as an alternative to the above discussed indications in 5GS registration type information). After step <b>408</b>, AMF <b>320</b> initiates UE authentication processes with an AUSF and selects AUSF <b>355</b> based on, for example, SUCI/SUPI information (described in 3GPP TS 23.501) and/or the indicated support for the blockchain authorization procedure.

0088Steps <b>410</b>-<b>425</b> illustrate the blockchain registration procedure employed by AUSF <b>355</b> in conjunction with conventional authentication calls (e.g., as specified by 3GPP TS 33.501) between AMF <b>320</b>, AUSF <b>355</b>, and UDM <b>360</b>. As described herein, the ordering and exchange messages represented by steps <b>410</b>-<b>425</b> can reflect various bi-lateral message exchanges.

0089In particular, step <b>410</b> represents an message exchange of challenges/responses between AMF <b>320</b> and UE <b>308</b>, which allow UE <b>308</b> to indicate support for the blockchain registration procedure in NAS messages sent to AMF <b>320</b> (e.g., over network interface N1).

0090At step <b>412</b>, AMF <b>320</b> can invoke existing authentication services by sending an authentication request message to AUSF <b>355</b>. In response, AUSF <b>355</b> checks that the requesting AMF in the serving network is entitled to use the serving network and sends, at step <b>414</b>, a corresponding authentication request message to UDM <b>360</b>. UDM <b>360</b> generates and sends an authentication vector (e.g., security keys, etc.) to AUSF <b>355</b>, again at step <b>414</b>.

0091AUSF <b>355</b> also exchanges EAP-Requests/AKA-Challenges with AMF <b>320</b>, at step <b>416</b>, which further solicit EAP challenges/responses from UE <b>308</b>, at step <b>418</b>. As shown, the EAP challenges/responses between UE <b>308</b> and AMF <b>320</b> can include NAS messages with blockchain payload data to provide AMF <b>320</b> (and thus AUSF <b>355</b> at step <b>416</b>) relevant blockchain authentication information (e.g., UE <b>308</b> registration information with prior BRB entities, prior BAF entities, etc.) for subsequent or secondary authentication by BAF <b>305</b> (e.g., steps <b>424</b>-<b>425</b> discussed below). In accordance with existing authentication protocols, and based on the EAP challenges/responses received by AUSF <b>355</b> at step <b>416</b>, AUSF <b>355</b> can complete UE authentication with UDM <b>360</b> at step <b>414</b>.

0092Collectively, the messages exchanged at steps <b>410</b>-<b>416</b> can confirm/accept the UE's credentials or deny/reject the UE's credentials based on existing authentication protocols. In addition, these messages can provide appropriate security context/acknowledgements between UE <b>308</b>, AMF <b>320</b>, AUSF <b>355</b>, and UDM <b>360</b>, which protect/encrypt subsequent messages from UE <b>308</b>.

0093Regardless of success/failure of UE authentication in steps <b>410</b>, AMF <b>320</b> and AUSF <b>355</b> may further perform the blockchain registration procedure (e.g., as a complimentary/substitute authentication procedure). In this fashion, the blockchain authentication procedure can thought of as an extension to existing calls and/or may include additional flags/parameters in appropriate messages.

0094Depending on policies and/or security requirements, AMF <b>320</b> may continue on to perform the blockchain authentication process with AUSF <b>355</b>. As mentioned above, AMF <b>320</b> can receive relevant blockchain authentication information from UE <b>308</b> in the course of exchanging authentication messages based on existing procedures, or alternatively, UE <b>308</b> can send separate NAS messages to AMF <b>320</b> with the blockchain authentication information included in payload data, such as shown at step <b>420</b>. The blockchain authentication information is used by AMF <b>320</b>/AUSF <b>355</b> to authenticate UE <b>308</b> with BRB <b>306</b> and thus, BAF <b>305</b>. For example, the blockchain authentication information can include a blockchain entity ID that corresponds to BRB <b>306</b> and/or BAF <b>305</b> as well as blockchain credentials, such as blockchain registration information, blockchain subscription information, and so on. Preferably, UE <b>308</b> registers and subscribes to BRB <b>306</b> and/or BAF <b>305</b> (e.g., over blockchain network interface BCz) to obtain the appropriate blockchain authentication information. AMF <b>320</b> receives these NAS messages, and sends corresponding blockchain authentication messages to BRB <b>306</b>. BRB <b>306</b> identifies the blockchain entity ID from the authentication messages, and selects an appropriate BAF (here, BAF <b>305</b>) to authenticate UE <b>308</b>.

0095At step <b>422</b>, AMF <b>320</b> further invokes AUSF <b>355</b> to continue the blockchain authentication procedure and authenticate UE <b>308</b> with BRB <b>306</b> using, for example, an API message (e.g., a Nausf service call over the N12 network interface). In this fashion, AMF <b>320</b> sends service-based API messages (e.g., as defined by 3GPP TS 29.509 and TS 29.518) with appropriate blockchain authentication flags/parameters/payload/etc. to AUSF <b>355</b>.

0096AUSF <b>355</b> receives the API messages and exchanges, at step <b>424</b>, blockchain authentication messages with BRB <b>306</b> over blockchain network interface BCx, which further causes BRB <b>306</b> to authenticate UE <b>308</b> with BAF <b>305</b> (e.g., based on the authentication data associated with UE <b>308</b>). In this fashion, BRB <b>306</b> authenticates UE <b>308</b> with BAF <b>305</b> at step <b>425</b>, and may receive a blockchain authentication confirmation message from BAF <b>305</b>. BRB <b>306</b> sends the confirmation message to AUSF <b>355</b>, which further sends the blockchain authentication confirmation messages to AMF <b>320</b>, as shown by the bi-lateral signals at steps <b>424</b> and <b>422</b>.

0097It is appreciated the blockchain authentication procedure may require additional messages to handle situations where BRB <b>306</b> is slow to respond, BAF <b>305</b> is unavailable or out of service, and/or fails to confirm the UE credentials. In these situations, AMF <b>320</b> may send temporary Ack messages to UE <b>308</b> to provide additional processing time for BRB <b>306</b> and/or BAF <b>305</b> to authenticate the UE credentials.

0098Steps <b>420</b>-<b>425</b> represent blockchain authentication operations where AMF <b>320</b> exchanges blockchain authentication data associated with UE <b>308</b> with BRB <b>306</b>, BRB <b>306</b> receives the blockchain authentication data and selects BAF <b>305</b> (e.g., based on a blockchain account identifier, UE blockchain credentials, etc.), and BRB <b>306</b> completes the blockchain authentication transaction with BAF <b>305</b>. In some embodiments, BAF <b>305</b> may be considered an agent of UE <b>308</b> and UE <b>308</b> can previously register and/or subscribe to BAF <b>305</b> over blockchain interface BCz (e.g., which can initially generate the blockchain authentication data associated with UE <b>308</b>).

0099Once UE <b>308</b> is successfully authenticated with the blockchain registration procedure, signaling diagram continues to steps <b>430</b>, <b>432</b>, <b>436</b>, and <b>438</b>, which include appropriate messages to complete UE <b>308</b> registration in accordance with 3GPP TS 23.502 (e.g., UDM selection/update, PCF selection, registration acceptance, and so on).

0100In some embodiments of this disclosure, the blockchain authentication procedure may also include an optional credit check for UE <b>308</b>, shown as a charging event at steps <b>434</b>-<b>435</b>. Notably, this credit check represents a charging authorization procedure that can be performed after UE <b>308</b> is authenticated with BRB <b>306</b>/BAF <b>305</b> but before AMF <b>320</b> attaches UE <b>308</b> to the SBA network.

0101In operation, PCF <b>345</b> manages mobility credentials for UE <b>308</b> and performs the credit authorization procedure with BRB <b>306</b>, which further communicates with BAF <b>305</b> in an authorization layer. The credit authorization procedure determines if UE <b>308</b> (and its corresponding user) can complete a transaction (e.g., can the user pay for the transaction now or at a future time), the type and/or number of network services the user can afford (e.g., which can limit or restrict access to network resources), and so on. For example, in an Internet of Things (IoT) context, PCF <b>345</b> can use the credit authorization procedure to determine virtual contract information (e.g., credit worthiness) associated with UE <b>308</b>, which can be shared with other network entities/services (e.g., NFs) in SBA <b>132</b>.

0102As mentioned above, steps <b>430</b>, <b>432</b>, <b>436</b>, and <b>438</b> include messages to complete UE <b>308</b> registration in accordance with 3GPP TS 23.502.

0103<figref idref="DRAWINGS">FIG. 4B</figref> provides signaling diagram <b>402</b>, which shows AMF <b>320</b> directly performing the blockchain registration procedure with BRB <b>306</b>. Signaling diagram <b>402</b> includes many of the same steps or calls shown in signaling diagram <b>401</b>, which are discussed above.

0104In this embodiment, AMF <b>320</b> directly perform the blockchain registration procedure with BRB <b>306</b> after, for example, AMF <b>320</b> successfully obtains an appropriate security context/acknowledgements from AUSF <b>355</b>/UDM <b>360</b>, which ensures encryption/integrity protection for messages exchanged with UE <b>308</b>.

0105In addition to the steps shown in signaling diagram <b>401</b>, signaling diagram <b>402</b> further provides steps <b>426</b>, <b>428</b>, and <b>429</b>, which represent messages directly exchanged between AMF <b>320</b> and BRB <b>306</b> and between BRB <b>306</b> and BAF <b>305</b>.

0106In particular, at step <b>426</b>, UE <b>308</b> exchanges blockchain authentication data with AMF <b>320</b> using, for example, NAS messages that can include blockchain payload data. In some embodiments, AMF <b>320</b> can select BRB <b>306</b> based on the blockchain authentication data, while in other embodiments, AMF <b>320</b> may be assigned to BRB <b>306</b> by default.

0107AMF <b>320</b> sends the authentication data to BRB <b>306</b> at step <b>428</b>. As mentioned, the blockchain authentication data can include a blockchain entity ID that corresponds to BAF <b>305</b> as well as blockchain credentials (e.g., registration information, subscription information, account information, etc.) that corresponds to UE <b>308</b>. BRB <b>306</b> receives the blockchain authentication data and can select an appropriate BAF (here, BAF <b>305</b>) based on the blockchain entity ID. BRB <b>306</b> further authenticates UE <b>308</b> with BAF <b>305</b> at step <b>429</b>, and upon successful authentication, BAF <b>305</b> sends an authentication confirmation to BRB <b>306</b>. BRB <b>306</b> further sends the authentication confirmation to AMF <b>320</b> at step <b>428</b> (which represents a bi-lateral message exchange).

0108Steps <b>430</b>, <b>432</b>, <b>436</b>, and <b>438</b> represent messages for completing UE registration in accordance with 3GPP TS 23.502.

0109Blockchain Enhanced PDN Session Establishment with Out-of-Band Blockchain Authorization

0110<figref idref="DRAWINGS">FIGS. 5A and 5B</figref> illustrate respective schematic signaling diagrams <b>500</b> and <b>501</b> of the disclosed blockchain enhanced session management processes using a natively integrated blockchain platform. Although the schematic signaling diagrams illustrate an initial session establishment procedure for a PDU session, it is appreciated the call flows may be readily modified according to handover operations, switching sessions, requesting sessions for emergency services, and the like.

0111<figref idref="DRAWINGS">FIG. 5A</figref> particularly illustrates schematic signaling diagram <b>500</b> showing call flows for a blockchain enhanced PDU session establishment with an out-of-band authorization operations. In general, the illustrated blockchain session establishment procedure leverages a new blockchain network interface (BCy) to authenticate UE <b>308</b> for network services and incorporates NEF <b>335</b> to act as an API gateway between SMF <b>325</b> and BRB <b>306</b>. In addition, <figref idref="DRAWINGS">FIG. 5A</figref> also illustrates blockchain charging events (e.g., steps <b>522</b>, <b>524</b>, and <b>525</b>) between PCF <b>345</b>, BRB <b>306</b>, and BAF <b>305</b>, which operably provide funds (e.g., tokens from an eWallet or blockchain wallet) directly for one or more network services.

0112As shown, at step <b>502</b>, UE <b>308</b> initiates an initial PDU (or PDN) session establishment request and sends session request data (e.g., Non-Access Stratum (NAS) messages) to AMF <b>320</b> over network interface N1. The NAS messages can include information such as Single Network Slice Selection Assistance Information (S-NSSAI), Data Network Name (DNN), PDU session IDs, request types, old PDU session IDs, an N1 Service Management (SM) container, indications/requests for blockchain authorization (e.g., as a secondary authorization), and so on.

0113Notably, the indications/requests for the blockchain authorization can represent a preference by UE <b>308</b> for the network (SBA <b>132</b>) to use blockchain authentication data (e.g., blockchain credentials) to authorize/authenticate UE <b>308</b> for a PDU session. In one embodiment, the indication of the blockchain authorization may be specified by the S-NSSAI data, which can include a unique identifier of a network slice. For example, the S-NSSAI data can include a Slice/Service type (SST), denoting expected network behaviour, as well as a Slice Differentiator (SD), differentiating amongst multiple network slices of the same Slice/Service type. Here, UE <b>308</b> can provide S-NSSAI data having a particular unique identifier corresponding to blockchain capable network slice.

0114Alternatively, the indication of the blockchain authorization may be included as one of the SST values in the S-NSSAI data in accordance with 3GPP TS 23.501 (clause 5.15, table 5.15.2.2-1). For example, the SST value may be modified to include the blockchain ID as provided below.

0115<tables id="TABLE-US-00004" num="00004"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="42pt" align="center" /><colspec colname="3" colwidth="140pt" align="left" /><thead><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Slice/Ser-</entry><entry>SST</entry><entry /></row><row><entry>vice type</entry><entry>value</entry><entry>Characteristics.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>eMBB</entry><entry>1</entry><entry>Slice suitable for the handling of 5G </entry></row><row><entry /><entry /><entry>enhanced Mobile Broadband.</entry></row><row><entry>URLLC</entry><entry>2</entry><entry>Slice suitable for the handling of ultra- </entry></row><row><entry /><entry /><entry>reliable low latency communications.</entry></row><row><entry>MIoT</entry><entry>3</entry><entry>Slice suitable for the handling of massive IoT.</entry></row><row><entry>Blockchain</entry><entry>X</entry><entry>Slice that uses blockchain for authorization </entry></row><row><entry /><entry /><entry>and/or service provisioning.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0116In other embodiments, if slicing is orthogonal to the blockchain procedures, the PDU “Request Type” could be set to “guest access with dual authentication”, as is appreciated by those skilled in the art.

0117AMF <b>320</b> receives the session establishment request and further discovers/selects an appropriate SMF—here, SMF <b>325</b>. In particular, AMF <b>320</b> discovers and selects SMF <b>325</b> based on parameters included in the initial PDU session request (e.g., step <b>502</b>). As mentioned, these parameters include S-NSSAI data, DNN data, UE subscriptions, local operator policies, blockchain authentication data/blockchain capabilities, and so on.

0118Here, AMF <b>320</b> selects SMF <b>325</b> based, at least in part, on its blockchain session capabilities. If AMF <b>320</b> does not have an association with an SMF for the PDU session ID (e.g., when Request Type indicates “initial request”), AMF <b>320</b> invokes a PDU session creation request (e.g., Nsmf_PDUSession_CreateSMContext Request), as shown at step <b>504</b>. However, if AMF <b>320</b> already has an association with an SMF for the PDU Session ID (e.g., when Request Type indicates “existing PDU Session”), the AMF invokes the Nsmf_PDUSession_UpdateSMContext Request. Notably, the PDU Session creation request can specify a request type set to “guest access with dual authentication” (e.g., if a slice is not explicitly set for blockchain authorization).

0119At steps <b>506</b> and <b>507</b>, SMF <b>325</b> exchanges registration/subscription information (e.g., associated with UE <b>308</b>) with UDM <b>360</b> through BRB <b>306</b>. Again, at step <b>504</b>, SMF <b>325</b> sends a corresponding PDU session SM context responses (e.g., an SM context identifier) to AMF <b>320</b>. In this fashion, SMF <b>325</b> registers itself for an initial PDU session with UDM <b>360</b>, in accordance with UE-requested PDU Session Establishment procedures provided by 3GPP TS 23.502.

0120Steps <b>508</b>-<b>514</b> represent operations of the disclosed blockchain session management, including out-of-band blockchain authorization/authentication operations as part of the PDN session establishment. These blockchain authorization/authentication operations may conform to secondary authentication/authorization operations such as Data Network (DN)-Authentication, Authorization, and Accounting (AAA) server, described by 3GPP TS 23.501, clause 5.6.6. As shown, the blockchain authorization/authentication operations further leverage the natively integrated blockchain platform (e.g., BRB <b>306</b> and/or BAF <b>305</b>) which is exposed to SBA <b>132</b> over a new blockchain network interfaces BCy and/or BCx.

0121In particular, at step <b>508</b>, UE <b>308</b> sends a NAS SM DN Request Container message to SMF <b>325</b> to request the blockchain authentication procedure as a secondary authorization for the PDN session (e.g., in accordance with secondary authorization request of 3GPP TS 23.501, clause 5.6.6). The NAS SM DN Request Container message includes blockchain information for PDU session authorization by an external Data Network (e.g., slice information (identified by S-NSSAI), PDU session ID, a PDN it would like to connect to (identified by DNN), a blockchain server ID (identifying BAF <b>305</b>), etc.). This blockchain information may be provided as part of payload data, and/or may be included as part of follow-on request data.

0122Although the NAS SM DN Request Container message is illustrated as a single signal between UE <b>308</b> and SMF <b>325</b>, it is appreciated this signal may be conveyed to SMF <b>325</b> by AMF <b>320</b>. For example, UE <b>308</b> can send the signal to AMF <b>320</b> over the N1 network interface, and AMF <b>320</b> can send or forward the signal (or appropriate portions of the signal) to SMF <b>325</b> over the N11 network interface. In some embodiments, the NAS SM DN Request Container can include the PDU session establishment request message (e.g., step <b>502</b>) as part of a N1 SM container, as is appreciated by those skilled in the art.

0123SMF <b>325</b> receives the NAS SM DN Request Container, and determines an appropriate BRB entity and/or appropriate BAF entity (e.g., a blockchain server) based on the blockchain information and local configuration information contained therein. For example, SMF <b>325</b> can determine BRB <b>306</b> is as the appropriate blockchain roaming broker and further exchange blockchain Application Programming Interface (API) messages with BRB <b>306</b> over a blockchain network interface (e.g., the BCx network interface).

0124At step <b>510</b>, SMF <b>325</b> exchanges the blockchain API messages with BRB <b>306</b>, using NEF <b>335</b>, which acts as a gateway between SMF <b>325</b> and BRB <b>306</b>. NEF <b>335</b> further exchanges, at steps <b>511</b>-<b>513</b>, corresponding Representational State Transfer (REST) API messages with BRB <b>306</b>. In this fashion, NEF <b>335</b> allows external users (e.g., enterprises/partner operations) to monitor, provision, and enforce application-level policy for users inside the operator network. In addition, just as NEF <b>335</b> can act as a gateway between SMF <b>325</b> and BRB <b>306</b>, BRB <b>306</b> can act as a gateway between NEF <b>335</b> (and/or other NFs) and BAF <b>305</b>.

0125Steps <b>511</b>-<b>514</b> continue until successful authorization or failure. At step <b>514</b>, BAF <b>305</b> sends BRB <b>306</b> authentication confirmation data (e.g., indicating successful session authorization and profile information), which is further sent to NEF <b>335</b> at step <b>513</b>, which further forwards the authentication confirmation data to SMF <b>325</b> at step <b>510</b>.

0126Notably, the authentication confirmation data can include a service name that BAF <b>305</b> uses to register available network services for UE <b>308</b>. In addition, BAF <b>305</b> may provide service specific attributes (e.g., application access capabilities, QoS and Data rate profiles and other applications that the user has subscribed to as part of the blockchain contract, etc.) Notably, if authorization fails, the PDU set up request is rejected with appropriate cause code.

0127After successful authorization, SMF <b>325</b> continues with PDU establishment operations and, based on a PDU profile, selects a PCF and performs Session Management Policy Establishment procedure, as shown at step <b>516</b>. SMF <b>325</b> can provide a blockchain flag and associated parameters (if available from UE <b>308</b>) to indicate to PCF <b>345</b> that service capabilities can be obtained from BAF <b>305</b> (e.g., and/or via NEF <b>335</b>). For example, PCF <b>345</b> can use the blockchain authentication data (received from SMF <b>325</b> at step <b>516</b>) to identify NEF <b>335</b> and/or BAF <b>305</b>.

0128PCF <b>345</b> requests, at step <b>518</b>, service parameters from NEF <b>335</b>, which further obtains the service parameters from BAF <b>305</b>. Notably, step <b>518</b> may be optional, because PCF <b>345</b> can use the UDR as per 4.16.4 procedure defined in 3GPP TS 23.502. However, in some instances, the UDR may not have a service profile for all use cases (e.g., where the UE is a guest on the service provider's network). As shown here, PCF <b>345</b> retrieves the service profile from NEF <b>335</b> (which NEF <b>335</b> retrieves from BAF <b>305</b>). PCF <b>345</b> further determines the network services, QoS, and charging plan to be applied to the PDU session associated with UE <b>308</b>.

0129SMF <b>325</b> further selects a UPF (e.g., UPF <b>315</b>) to serve the PDU session, and at steps <b>520</b>-<b>524</b>, SMF <b>325</b> performs a blockchain charging event in conjunction with PCF <b>345</b>, NEF <b>335</b>, and/or BAF <b>305</b>, based on the profile information received at step <b>514</b>.

0130In particular, SMF <b>325</b> requests PCF <b>345</b> and NEF <b>335</b> to perform the blockchain charging event, which can represent a credit request transaction. The blockchain charging event includes operations for BAF <b>305</b> to return blockchain payment credits (e.g., blockchain tokens) to PCF <b>345</b> and/or SMF <b>325</b> (e.g., through BRB <b>306</b>) in order to pay for one or more network services for UE <b>308</b>. For example, the BAF <b>305</b> can return blockchain tokens from a blockchain eWallet associated with UE <b>308</b>.

0131In some instances, SMF <b>325</b> and PCF <b>345</b> can return tokens to BAF <b>305</b>, again through BRB <b>306</b>, should all the tokens requested in this step not be consumed. In comparison to other pre-paid services that use quotas from an Online Charging Server (OCS) (not an actual monetary fund), the blockchain charging event represents a prepaid transaction that can include actual funds, which the service provider can return if the contract is not completed in an authorized time period.

0132The blockchain charging event may include messages exchanged over the N30 network interface, shown at step <b>522</b>, between PCF <b>345</b> and NEF <b>335</b>. In this fashion, Nnef API messages may be augmented to include appropriate blockchain eWallet messages (requests/returns/etc.)

0133Steps <b>524</b>-<b>525</b> represent trusted communications between NEF <b>335</b>, BRB <b>306</b>, and BAF <b>305</b> since BAF <b>305</b> is a trusted application. However, in some instances, BAF <b>305</b> may not be trusted, in which case an Application Function (AF) could provide a proxy for these procedures.

0134In one or more additional embodiments, enhanced blockchain session management operations also accommodate delayed authorization. For example, BAF <b>305</b> and/or BRB <b>306</b> may require a certain amount of time to conclude a consensus, which may delay its response/fund verifications (e.g., as part of the blockchain charging event). In these instances, SMF <b>325</b> can request PCF <b>345</b> to notify it when NEF <b>335</b> allows the subscription. In addition, SMF <b>325</b> concludes the PDU session establishment, but can indicate UPF <b>315</b> to place the PDU session in quarantine until further notice (e.g., until BAF <b>305</b> concludes the consensus/completes the charging event).

0135Remaining steps <b>526</b>-<b>548</b>, may be defined by 3GPP TS 23.502, as is appreciated by those skilled in the art.

0136Blockchain Enhanced PDN Session Establishment with in-Band Blockchain Authorization

0137<figref idref="DRAWINGS">FIG. 5B</figref> illustrates a schematic signaling diagram <b>501</b>, showing call flows for a blockchain enhanced PDU session establishment with in-band authorization operations. The in-band blockchain session establishment procedure of <figref idref="DRAWINGS">FIG. 5B</figref> particularly leverages blockchain messages between UE <b>308</b> and BAF <b>305</b> (and/or through DN <b>108</b>) using Internet Protocol (IP) datagram encapsulation, as discussed in greater detail below.

0138Signaling diagram <b>501</b> begins at step <b>502</b> where, as discussed above, UE <b>308</b> initiates a PDU session establishment request. The session establishment call flow follows the above-discussed operations for steps <b>504</b>, <b>506</b>, and <b>507</b>.

0139At step <b>508</b>, UE <b>308</b> sends a NAS SM DN Request Container message to SMF <b>325</b> to request the blockchain authentication procedure as a secondary authorization for the PDN session. As mentioned, the NAS SM DN Request Container message includes blockchain information for PDU session authorization by an external Data Network (e.g., slice information (identified by S-NSSAI), PDU session ID, a PDN it would like to connect to (identified by DNN), a blockchain server ID (identifying BAF <b>305</b>), etc.) Notably, step <b>508</b> represents an optional signal between UE <b>308</b> and SMF <b>325</b>. However, even though it is optional, step <b>508</b> helps build trust between the core network (e.g., SBA <b>132</b>) and BAF <b>305</b> (e.g., a Distributed Ledger Technology (DLT) entity). For example, as discussed in greater detail below, until the blockchain authentication procedure results in successful authorization of the UE, UE <b>308</b> may only have a temporary connection and the access control list may be restricted. BAF <b>305</b> is typically registered and authenticated with NEF <b>335</b>, and SMF <b>325</b> may invoke NEF <b>335</b> to pass on the blockchain authentication credentials. Once authorized, UE <b>308</b> is notified of successful authorization, and BAF <b>305</b> notifies NEF <b>335</b>, which (in turn) notifies SMF <b>325</b> of the successful authorization.

0140Steps <b>510</b>-<b>514</b> (not shown) apply for the out-of-band blockchain authentication operations (e.g., secondary authentication/authorization operations), and are illustrated in signaling diagram <b>500</b>. Here, signaling diagram <b>501</b> illustrates in-band authentication operations, which are performed later in the signal flow (e.g., steps <b>550</b>-<b>560</b>), as described below.

0141In proper context, UE <b>308</b> is attached to the network at step <b>508</b>, but does not have an IP address assigned. After step <b>508</b>, SMF <b>325</b> selects PCF <b>345</b> based on a PDU profile. PCF <b>345</b> performs the Session Management Policy Establishment procedure, shown by steps <b>516</b>-<b>518</b>. For example, the Session Management Policy Establishment procedure can include operations where SMF <b>325</b> establishes the PDU Session with PCF <b>345</b>, including SMF <b>325</b> receiving default PCC Rules for the PDU Session, PCF <b>345</b> subscribing to IP allocation/release events in SMF <b>325</b>, PCF <b>345</b> updating policy information in SMF <b>325</b>, and so on.

0142Following steps <b>516</b>-<b>518</b>, SMF <b>325</b> selects a UPF (e.g., UPF <b>315</b>) to serve the PDU session. In case of PDU Type IPv4 or IPv6, SMF <b>325</b> allocates an IP address/prefix for the PDU Session as described in 3GPP TS 23.501, clause 5.8.1. In case of a PDU Type IPv6, SMF <b>325</b> can allocate an interface identifier to UE <b>308</b> for the UE to build its link-local address. For Unstructured PDU 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 3GPP TS 23.501, clause 5.6.10.3.

0143Step <b>520</b> is modified since the above-discussed out-of-band blockchain authentication operations do not occur (e.g., steps <b>510</b>-<b>514</b>) here. Instead, at step <b>520</b>, PCF <b>345</b> determines UE <b>308</b> requests the blockchain authentication/authorization procedure. For example, SMF <b>325</b> can provide a blockchain indication to PCF <b>345</b>, which blockchain indication can include a blockchain flag, blockchain authentication data, payment data, blockchain entity identifiers, and so on. Here, the blockchain indication includes a blockchain flag, which causes PCF <b>345</b> to apply a restricted or guest access policy for the PDU session, pending successful in-band blockchain authorization/authentication operations, discussed below. Put differently, PCF <b>345</b> installs a restricted access rule for the PDU session, which may be similar to the rules applied for pre-paid users (e.g., users can access a Domain Name Server (DNS) to resolve the servers and HTTPS port/destination pair to a set of servers, etc.) In some embodiments, the server IP addresses could be returned in step <b>522</b> and step <b>524</b> as part of a blockchain charging event (not shown here).

0144If there is a commercial agreement in place, the restricted access policy allows UE <b>308</b> access to DN <b>108</b> to obtain authentication/authorization and blockchain payment data/tokens from BAF <b>305</b>. Again, similar to the pre-paid restricted policies, which allows UE <b>308</b> to connect to DN <b>108</b> through a web portal and enter credit card information, the in-band blockchain authentication/authorization operations represented by steps <b>550</b>-<b>562</b> leverage the native blockchain platform to automatically debit blockchain payments/tokens from BAF <b>305</b>. In this fashion, the subscriber associated with UE <b>308</b> only needs to ensure their wallet has funds.

0145Following step <b>520</b>, SMF <b>325</b> provisions rules on UPF <b>315</b>, at steps <b>526</b>-<b>528</b>, to allow DNS requests and REST messages to BAF <b>305</b> (e.g., a DLT server address provided by PCF <b>345</b>).

0146Steps <b>530</b>-<b>548</b> represent signals or messages accordance with UE-requested PDU Session Establishment procedures provided by 3GPP TS 23.502.

0147Steps <b>550</b>-<b>560</b> represent in-band blockchain authentication/authorization signals or messages. While steps <b>550</b>-<b>560</b> are illustrated after the PDU session is established at step <b>548</b> with a restricted access policy, it is appreciated these signals or messages may begin at step <b>538</b> (Up Link (UL) traffic).

0148At step <b>550</b>, UE <b>308</b> sends blockchain authentication data to UPF <b>315</b> using IP datagram encapsulation. UPF <b>315</b> acts as a gateway to BAF <b>305</b> and sends, at step <b>552</b>, corresponding blockchain data to BAF <b>305</b>. In some embodiments, UPF <b>315</b> may send messages to other NFs (e.g., SMF <b>325</b>) and/or over DN <b>108</b> for forwarding to BAF <b>305</b>. However, for sake of simplicity, signaling diagram <b>501</b> shows UPF <b>315</b> sending the corresponding blockchain data directly to BAF <b>305</b>. The blockchain authentication data can include, for example, blockchain authentication credentials, blockchain entity identifiers (e.g., corresponding to BAF <b>305</b>), and other information required by BAF <b>305</b> to authenticate/authorize UE <b>308</b> as well as to solicit blockchain payment data (e.g., blockchain tokens).

0149In this fashion, DN <b>108</b> may treat the PDU session as a prepaid session and allow approved protocols. In some embodiments, the PDU session may be associated with a timer that can safeguard the session and terminate the session if the PDU authentication/authorization does not conclude within a predetermined timeframe. In these embodiments, UDM <b>360</b> can set the timeframe at step <b>506</b> and/or the timeframe may be locally configured as part of an APN profile.

0150Steps <b>550</b>-<b>553</b> represent bi-directional messages between UE <b>308</b>, UPF <b>315</b>, BRB <b>306</b>, and BAF <b>305</b>. Other NFs (e.g., NEF <b>335</b>, DN <b>108</b>, etc.) may be invoked or employed as is appreciated by those skilled in the art. The bi-directional messages include blockchain authentication data required by BAF <b>305</b> to authenticate/authorize UE <b>308</b> as well as to solicit blockchain payment data (e.g., blockchain tokens). If authorization fails at steps <b>550</b>-<b>553</b>, UE <b>308</b> can choose to disconnect from the network. The network (e.g., SBA <b>132</b>) would be notified at steps <b>556</b>-<b>558</b>, and may further block UE <b>308</b>, disconnect the PDU session, or try authentication again.

0151BAF <b>305</b> authenticates (e.g., verifies blockchain credentials for UE <b>308</b>) the blockchain credentials associated with UE <b>308</b> and, if successful, it notifies NEF <b>335</b> (step <b>554</b>), which in turn notifies PCF <b>345</b> (step <b>556</b>) regarding successful authentication. Notably, BRB <b>306</b> may act as a gateway to facilitate communications between NEF <b>335</b> and BAF <b>305</b>. In addition, BAF <b>305</b> can return blockchain payment data (e.g., blockchain tokens) to NEF <b>335</b> and/or PCF <b>345</b>. PCF <b>345</b> updates the policy/traffic rules for SMF <b>325</b>, at step <b>558</b>, which further updates the traffic rules with UPF <b>315</b>. The updated policy/traffic rules permit UE <b>308</b> access to contracted network services (e.g., as specified and/or as paid for by BAF <b>305</b>).

0152The call flows or messages shown in <figref idref="DRAWINGS">FIG. 5B</figref> illustrate an in-band blockchain enhanced PDU session establishment procedure where BAF <b>305</b> authenticates UE <b>308</b> and returns blockchain payment data (e.g., blockchain tokens) to appropriate NFs in SBA <b>132</b> using IP datagram encapsulation.

0153<figref idref="DRAWINGS">FIG. 6</figref> illustrates an example simplified procedure <b>600</b> for registering User Equipment (UE) in accordance with one or more embodiments of the blockchain registration procedure. For example, procedure <b>600</b> can represent operations performed by a NF entity (e.g., AMF <b>320</b>, AUSF <b>355</b>, NEF <b>335</b>, etc.) as part of the 5G core network.

0154Procedure <b>600</b> begins at step <b>605</b> and continues on to step <b>610</b> where, as discussed above, a core NF entity receives authentication data associated with a User Equipment (UE). The NF entity further determines the UE is roaming relative to the core network at step <b>615</b> and also determines the UE supports a blockchain registration procedure at step <b>620</b>. At step <b>625</b>, the NF entity can select a Blockchain Roaming Broker (BRB—e.g., BRB <b>306</b>) and exchange, at step <b>630</b>, authentication messages with the BRB entity. The BRB entity typically acts as an agent of a Blockchain Authentication Function (BAF) entity. In this fashion, the BRB entity can receive the authentication messages (which can include authentication data) and authenticate the UE with the BAF entity. The BRB entity can further send corresponding blockchain authentication confirmation messages from the BAF to the NF, as illustrated in step <b>635</b>.

0155In addition, in some embodiments, the NF can perform a credit authorization procedure for a user associated with the UE, as shown at step <b>640</b>. For example, the NF can include a PCF entity, which can communicate with the BRB entity and/or the BAF entity to determine if the user has appropriate funds (e.g., in an eWallet or a blockchain account) to pay for requested network services.

0156At step <b>645</b>, the NF entity registers the UE with the core network based on the blockchain authentication confirmation (e.g., received from the BRB entity), and at step <b>650</b>, the NF entity provides access to one or more network resources based on the credit authorization procedure.

0157Procedure <b>600</b> subsequently ends at step <b>655</b>, but may return again to step <b>510</b> where the NF receives authentication for another UE.

0158It should be noted that while certain steps within procedure <b>600</b> may be optional, the steps shown in <figref idref="DRAWINGS">FIG. 6</figref> are merely example steps for illustration—certain other steps may be included or excluded as desired. Further, while a particular order of the steps is shown, this ordering is merely illustrative, and any suitable arrangement of the steps may be utilized without departing from the scope of the embodiments herein.

0159The techniques described herein, therefore, provide a native blockchain platform for wireless networks. This native blockchain platform supports new use cases that create opportunities to share network resources across multiple provider networks, increase workload mobility security, improve billing/mediation and reconciliation and create mechanisms for roaming authentication/registration using blockchain technology. In addition, the native blockchain platform provides new opportunities for the app economy and creates a new market place for Mobile virtual network operators (MVNO) participation. As discussed above the native blockchain platform facilitates new methods for authenticating UE when attaching the UE to the network as well as new methods to facilitate payments for network services as part of blockchain charging events.

0160While there have been shown and described illustrative embodiments of the native blockchain platform and corresponding operations in a specific network context (e.g., a mobile core network for a 5G network), it is to be understood that various other adaptations and modifications may be made within the spirit and scope of the embodiments herein. For example, the embodiments and operations disclosed herein have been described with respect to certain devices, NFs, interfaces, and systems, however it is appreciated that such embodiments are provided for purposes of example, not limitation and that the blockchain authentication techniques disclosed herein can be incorporated as part of existing wireless networks.

0161The foregoing description has been directed to specific embodiments. It will be apparent, however, that other variations and modifications may be made to the described embodiments, with the attainment of some or all of their advantages. For instance, it is expressly contemplated that the components, elements, and/or operations described herein can be implemented as software being stored on a tangible (non-transitory) computer-readable medium, devices, and memories (e.g., disks/CDs/RAM/EEPROM/etc.) having program instructions executing on a computer, hardware, firmware, or a combination thereof. Further, methods describing the various functions and techniques described herein can be implemented using computer-executable instructions that are stored or otherwise available from computer readable media. Such instructions can comprise, for example, instructions and data which cause or otherwise configure a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Portions of computer resources used can be accessible over a network. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, firmware, or source code. Examples of computer-readable media that may be used to store instructions, information used, and/or information created during methods according to described examples include magnetic or optical disks, flash memory, USB devices provided with non-volatile memory, networked storage devices, and so on. In addition, devices implementing methods according to these disclosures can comprise hardware, firmware and/or software, and can take any of a variety of form factors. Typical examples of such form factors include laptops, smart phones, small form factor personal computers, personal digital assistants, and so on. Functionality described herein also can be embodied in peripherals or add-in cards. Such functionality can also be implemented on a circuit board among different chips or different processes executing in a single device, by way of further example. Instructions, media for conveying such instructions, computing resources for executing them, and other structures for supporting such computing resources are means for providing the functions described in these disclosures. Accordingly this description is to be taken only by way of example and not to otherwise limit the scope of the embodiments herein. Therefore, it is the object of the appended claims to cover all such variations and modifications as come within the true spirit and scope of the embodiments herein.