U.S. patent application number 16/134887 was filed with the patent office on 2019-12-12 for systems, devices, and techniques for registering user equipment (ue) in wireless networks using a native blockchain platform.
The applicant listed for this patent is Cisco Technology, Inc.. Invention is credited to Ian McDowell Campbell, Aeneas Sean Dodd-Noble, Michael David Geller, Ammar Rayes, Om Prakash Suthar.
Application Number | 20190380030 16/134887 |
Document ID | / |
Family ID | 68617589 |
Filed Date | 2019-12-12 |
![](/patent/app/20190380030/US20190380030A1-20191212-D00000.png)
![](/patent/app/20190380030/US20190380030A1-20191212-D00001.png)
![](/patent/app/20190380030/US20190380030A1-20191212-D00002.png)
![](/patent/app/20190380030/US20190380030A1-20191212-D00003.png)
![](/patent/app/20190380030/US20190380030A1-20191212-D00004.png)
![](/patent/app/20190380030/US20190380030A1-20191212-D00005.png)
![](/patent/app/20190380030/US20190380030A1-20191212-D00006.png)
![](/patent/app/20190380030/US20190380030A1-20191212-D00007.png)
United States Patent
Application |
20190380030 |
Kind Code |
A1 |
Suthar; Om Prakash ; et
al. |
December 12, 2019 |
SYSTEMS, DEVICES, AND TECHNIQUES FOR REGISTERING USER EQUIPMENT
(UE) IN WIRELESS NETWORKS USING A NATIVE BLOCKCHAIN PLATFORM
Abstract
A network function (NF) entity in a communication network
determines a User Equipment (UE) supports a blockchain
authentication procedure, exchanges authentication messages with a
Blockchain Authentication Function (BAF) entity over a blockchain
network interface (e.g., based on the blockchain authentication
procedure), receives a blockchain authentication confirmation from
the BAF entity, and registers the UE based on the blockchain
authentication confirmation.
Inventors: |
Suthar; Om Prakash;
(Bolingbrook, IL) ; Dodd-Noble; Aeneas Sean;
(Andover, MA) ; Rayes; Ammar; (San Ramon, CA)
; Campbell; Ian McDowell; (Littleton, CO) ;
Geller; Michael David; (Weston, FL) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Cisco Technology, Inc. |
San Jose |
CA |
US |
|
|
Family ID: |
68617589 |
Appl. No.: |
16/134887 |
Filed: |
September 18, 2018 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62682770 |
Jun 8, 2018 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04W 88/02 20130101;
H04W 84/042 20130101; H04L 63/102 20130101; H04L 2209/80 20130101;
H04W 12/06 20130101; H04M 15/8038 20130101; H04L 12/1407 20130101;
H04W 4/24 20130101; H04W 48/18 20130101; H04L 2209/38 20130101;
H04M 15/66 20130101; H04L 63/0892 20130101; H04M 15/00 20130101;
H04M 15/8228 20130101; H04W 60/00 20130101; H04L 12/14 20130101;
H04W 48/08 20130101; H04W 12/08 20130101; H04L 9/0637 20130101;
H04L 9/3239 20130101; H04M 15/854 20130101 |
International
Class: |
H04W 12/06 20060101
H04W012/06; H04L 9/06 20060101 H04L009/06; H04L 29/06 20060101
H04L029/06; H04W 60/00 20060101 H04W060/00 |
Claims
1. A method for registering User Equipment in a communication
network, the method comprising: determining, by an Access and
Mobility Management Function (AMF) entity, a User Equipment (UE)
supports a blockchain authentication procedure; first receiving, by
the AMF entity, blockchain credentials from the UE; determining, by
the AMF entity, the blockchain credentials include a blockchain
entity identifier (ID); selecting, by the AMF, from amongst a
plurality of available Blockchain Authentication Function (BAF)
entities a particular BAF entity based on the blockchain entity ID;
exchanging, after the selecting, authentication messages between
the AMF entity and the selected BAF entity over a blockchain
network interface, based on the blockchain authentication
procedure; second receiving, by the AMF entity, a blockchain
authentication confirmation from the BAF entity; and registering,
by the AMF entity, the UE based on the blockchain authentication
confirmation.
2. The method of claim 1, wherein exchanging authentication
messages between the AMF entity and the BAF entity further
comprises: selecting an Authentication Server Function (AUSF)
entity to perform the blockchain authentication procedure; and
sending a blockchain authentication request to the AUSF entity to
cause the AUSF entity to authenticate the UE with the BAF entity
over a blockchain network interface, and wherein receiving the
authentication confirmation further comprises receiving the
authentication confirmation from the AUSF entity.
3. (canceled)
4. The method of claim 1, further comprising: receiving, by the AMF
entity, blockchain credentials in a Non-Access Stratum (NAS)
message from the UE, and wherein exchanging the authentication
messages further comprises exchanging the blockchain credentials
between the AMF entity and the BAF entity.
5. The method of claim 4, wherein the blockchain network interface
is a first blockchain network interface, wherein the UE receives
the blockchain credentials from the BAF entity over a second
blockchain network interface.
6. The method of claim 1, further comprising between the second
receiving and the registering: performing a credit authorization
procedure for a user associated with the UE; and providing the UE
access to one or more network resources based on the credit
authorization procedure.
7. The method of claim 6, wherein performing the credit
authorization procedure further comprises invoking, by the AMF, a
Policy Control Function entity to perform the credit authorization
procedure.
8. (canceled)
9. The method of claim 1, wherein determining the UE supports the
blockchain authentication procedure further comprises: receiving,
by the AMF entity, a registration request message associated with
the UE over at least one of a Radio Access Network (RAN) interface
or an Access Network (AN) interface; and determining the
registration request message indicates the UE supports blockchain
authentication in an access category.
10. The method of claim 1, wherein determining the UE supports the
blockchain authentication procedure further comprises: receiving,
by the AMF entity, a Non-Access Stratum (NAS) message associated
with the UE; and determining the NAS message indicates the UE
supports the blockchain authentication procedure based on at least
one of registration type data or follow-on request data.
11. The method of claim 1, wherein exchanging authentication
messages between the AMF entity and the BAF entity further
comprises exchanging one or more REST Application Program Interface
(API) messages between the AMF entity and the BAF entity.
12. (canceled)
13. A network function (NF) device, comprising: one or more network
interfaces to communicate within a communication network; a
processor coupled to the network interfaces and adapted to execute
one or more processes; and a memory configured to store
instructions executable by the processor, the instructions when
executed operable to: determine a User Equipment (UE) supports a
blockchain authentication procedure; first receive, by the AMF
entity, blockchain credentials from the UE; determine, by the AMF
entity, the blockchain credentials include a blockchain entity
identifier (ID); select, by the AMF, from amongst a plurality of
available Blockchain Authentication Function (BAF) entities a
particular BAF entity based on the blockchain entity ID; exchange,
after the select, authentication messages with the selected BAF
entity over a blockchain network interface, based on the blockchain
authentication procedure; second receive a blockchain
authentication confirmation from the BAF entity; and register the
UE based on the blockchain authentication confirmation.
14. The NF device of claim 13, wherein the instructions to exchange
authentication messages with the BAF entity are further operable
to: select an Authentication Server Function (AUSF) entity to
perform the blockchain authentication procedure; and send a
blockchain authentication request to the AUSF entity to cause the
AUSF entity to authenticate the UE with the BAF entity over a
blockchain network interface, and wherein the instructions to
receive the authentication confirmation message are further
operable to receive the authentication confirmation message from
the AUSF entity.
15. (canceled)
16. The NF device of claim 13, wherein the instructions, when
executed, are further operable to: receive blockchain credentials
in a Non-Access Stratum (NAS) message from the UE, and wherein the
instructions to exchange the authentication messages are further
operable to send the blockchain credentials to the BAF entity.
17. The NF device of claim 13, wherein the instructions, when
executed, are further operable to between the second receive and
the register: perform a credit authorization procedure for a user
associated with the UE; and provide the UE access to one or more
network resources based on the credit authorization procedure.
18. A tangible, non-transitory, computer-readable media having
instructions encoded thereon, the instructions, when executed by a
processor, are operable to: determine a User Equipment (UE)
supports a blockchain authentication procedure; first receive, by
the AMF entity, blockchain credentials from the UE; determine, by
the AMF entity, the blockchain credentials include a blockchain
entity identifier (ID); select, by the AMF, from amongst a
plurality of available Blockchain Authentication Function (BAF)
entities a particular BAF entity based on the blockchain entity ID;
exchange, after the select, authentication messages with the
selected BAF entity over a blockchain network interface, based on
the blockchain authentication procedure; second receive a
blockchain authentication confirmation from the BAF entity; and
register the UE based on the blockchain authentication
confirmation.
19. The tangible, non-transitory, computer-readable media of claim
18, wherein the instructions, when executed by the processor to
exchange authentication messages with the BAF entity, are further
operable to: select an Authentication Server Function (AUSF) entity
to perform the blockchain authentication procedure; and send a
blockchain authentication request to the AUSF entity to cause the
AUSF entity to authenticate the UE with the BAF entity over a
blockchain network interface, and wherein the instructions, when
executed by the processor to receive the authentication
confirmation message are further operable to receive the
authentication confirmation from the AUSF entity.
20. The tangible, non-transitory, computer-readable media of claim
18, wherein the instructions, when executed by the processor, are
further operable between the second receive and the register to:
perform a credit authorization procedure for a user associated with
the UE; and provide the UE access to one or more network resources
based on the credit authorization procedure.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims benefit to U.S. provisional
application No. 62/682,770, filed on Jun. 8, 2018, which is
expressly incorporated by reference herein in its entirety.
TECHNICAL FIELD
[0002] The present subject matter relates generally to
communication networks, and more particularly, to natively
integrating blockchain technologies in the context of registering
User Equipment (UE) in telecommunication networks (e.g., 4G, 5G,
etc.)
BACKGROUND
[0003] An 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.sup.rd Generation (3G) networks to
4.sup.th Generation (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.). For example, this service-oriented architecture supports
network slices, which employ an isolated set of programmable
resources that can 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. In turn, the
service-oriented architecture, including its network slice
implementation, creates opportunities to employ new mechanisms that
natively support such dynamic and flexible workload provisioning
and improve overall UE mobility.
BRIEF DESCRIPTION OF THE DRAWINGS
[0004] The 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] FIG. 1 illustrates a schematic block diagram of exemplary
telecommunication networks, including a 3G network, a 4G network,
and a 5G network;
[0006] FIG. 2 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] FIG. 3A 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] FIG. 3B illustrates a schematic block diagram of reference
point representation of the roaming architecture shown in FIG.
3A;
[0009] FIG. 4A illustrates a schematic signaling diagram, showing a
blockchain authentication procedure that invokes an Access and
Mobility Management Function (AMF) entity;
[0010] FIG. 4B illustrates a schematic signaling diagram, showing a
blockchain authentication procedure performed between an Access and
Mobility Management Function (AMF) entity and a Blockchain
Authentication Function (BAF) entity; and
[0011] FIG. 5 illustrates an example simplified procedure for
registering User Equipment (UE) in a communication network, in
accordance with one or more embodiments of the blockchain
authentication procedure.
DESCRIPTION OF EXAMPLE EMBODIMENTS
[0012] Overview
[0013] This 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 determines a UE supports a blockchain
authentication procedure. The NF entity exchanges authentication
messages with a Blockchain Authentication Function (BAF) entity
over a blockchain network interface and receives a blockchain
authentication confirmation from the BAF entity. The NF entity
further registers 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. Notably, the AMF
entity may communicate directly with the BAF 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 BAF entity over another blockchain network interface.
DESCRIPTION
[0014] Various 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.
[0015] As 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.
[0016] A 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.
[0017] FIG. 1 illustrates a schematic block diagram of exemplary
telecommunication networks 100, including a 3G network 110, a 4G
network 120, and 5G network 130. Telecommunication networks 100
include wireless network interfaces or communication links, such as
air interfaces 140, an access network 150, which represents radio
infrastructure or radio towers, and a core network 160, which
represents respective core network entities, network modules, or
Network Functions (NF(s)). The wireless network interfaces or air
interfaces 140 include Uu links for 3G network 110, LTE-Uu links
for 4G network 120, and 5G-NR links for 5G network 130. 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.
[0018] Those 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 100, 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.
[0019] Access network 150 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 150 includes NodeBs (NBs) for 3G network 110, eNodeBs
(eNBs) for 4G network 120, and gNodeBs (gNBs) for 5G network 130.
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.
[0020] Respective network entities that form core network 160
(within the telecommunication networks 100) operatively connect
respective RAN infrastructure (NBs, eNBs, gNBs) to third party
networks such as a voice network 105 (e.g., a Public Switched
Telephone Network (PSTN) network) and/or a data network 108 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 105
(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 108 (e.g., a packet switched
network). Core network 160 and its respective network entities
collectively operate to manage connections, bandwidth, and mobility
for respective UE.
[0021] Notably, core network 160 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 110, session management
includes a standalone General Packet Radio Service (GPRS) network,
while 4G network 120 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 120, 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).
[0022] 5G network 130, as discussed in greater detail herein,
introduces a new service base architecture (SBA) 132, 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 120) are realized as services rendered
through a new network function/entity called the User Plane
Function (UPF). In this fashion, 5G network 130 provides a modular
set of services that support dynamic and scalable deployment of
resources to satisfy diverse user demands.
[0023] FIG. 2 illustrates a schematic block diagram of an exemplary
network device or Network Function (NF) 200 that may be used with
one or more embodiments described herein, e.g., particularly as
User Equipment (UE) and/or other NFs within SBA 132 (e.g., an
Access and Mobility Management Function (AMF) entity,
Authentication Server Function (AUSF) entity, and so on).
[0024] The illustrative device 200 comprises one or more network
interfaces 210, at least one processor 220, and a memory 240
interconnected by a system bus 250. Network interface(s) 210
contain the mechanical, electrical, and signaling circuitry for
communicating data over links (e.g., wires or wireless links)
within the telecommunication networks 100 (e.g., ref. FIG. 1).
Network interfaces 210 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 210 may include new blockchain network interfaces (e.g.,
"BCx", "BCy", and/or "BCz") as discussed in greater detail
below.
[0025] Memory 240 comprises a plurality of storage locations that
are addressable by processor 220 for storing software programs and
data structures associated with the embodiments described herein.
Processor 220 may comprise necessary elements or logic adapted to
execute the software programs and manipulate data structures 245.
An operating system 242, portions of which are typically resident
in memory 240 and executed by processor 220, 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 "block chain registration" process/service 244 as well
as "session establishment" process/services 246, as described
herein. Note that while processes/services 244 and 246 are shown in
centralized memory 240, some embodiments provide for these
processes/services to be operated in a distributed communication
network.
[0026] Illustratively, the techniques described herein may be
performed by hardware, software, and/or firmware, such as in
accordance with the illustrative blockchain authentication process
244 and/or the illustrative session establishment process 246,
which may contain computer executable instructions executed by
processor 220 to perform functions relating to UE authentication
and/or UE session establishment described herein.
[0027] It 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 220 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 240,
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 244 and/or session
establishment process 246 encoded thereon. Processor 220 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.
[0028] As 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 132--FIG. 1). Traditional
processes employed by 3G and 4G networks to provision network
resource and support UE mobility (e.g., registration, session
establishment, session maintenance) 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. However, the 5G network introduces new
infrastructure that supports the service-oriented architecture,
which can provision network services/resources in a dynamic,
scalable, and customizable fashion using, for example, 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.
[0029] With respect to dynamic network resource and/or workload
provisioning, the 5G network also supports additional processes and
procedures for UE registration, session establishment, session
maintenance, and so on, which can improve network services for a
variety of devices with very different quality of service (QoS)
requirements. For example, as disclosed herein, this disclosure
provides complimentary and/or alternative mechanisms--e.g.,
blockchain registration capabilities--to natively support such
dynamic and flexible workload provisioning and improve overall UE
mobility.
[0030] Blockchain 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. However, despite its advantages, existing
protocols/network architectures in the telecommunications context
generally fail to support native blockchain technologies due, in
part, to underlying security requirements for initial registration
processes. Blockchain technologies can be employed within existing
telecommunication networks, however 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.
[0031] Accordingly, as described in greater detail herein,
embodiments of this disclosure provide a native blockchain platform
that employs blockchain operations that can serve as additional
and/or alternative registration processes within a mobile network,
and that further operates in conjunction with various mobile
Network Functions (NFs) or network entities (including UE) over new
blockchain network interfaces. In particular, these blockchain
authentication operations may satisfy security requirements for
network service providers, and can provide access to a variety of
new types of devices/users. In addition, the native blockchain
platform of this disclosure also supports 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.
[0032] Referring again to the figures, FIG. 3A illustrates a
schematic block diagram 301, showing a blockchain platform natively
integrated with a SBA 132 for an exemplary 5G network (e.g., 5G
network 130), and FIG. 3B illustrates a schematic block diagram
302, showing a reference point architecture for the blockchain
platform of FIG. 3A. Collectively, FIGS. 3A and 3B show a native
blockchain platform, an enterprise blockchain network 304, which
interconnects blockchain service providers (SPs) or Blockchain
Authentication Function (BAF) entities 305a-305n (e.g., distributed
ledger technology (DLT) entities, etc.) entities with various
network entities over blockchain network interfaces BCx, BCy, and
BCz. Notably, the blockchain interfaces can form network interfaces
210 for device/entity 200, discussed above.
[0033] The blockchain interfaces represent communication links that
facilitate an exchange of messages or data packets between BAF(s)
and SBA 132 (e.g., NFs that form SBA 132. In particular, 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.
[0034] Blockchain network 304 generally facilitates sharing network
resources or access to network functions (NFs) such as Access and
Mobility Management Function (AMF), Session Management Function
(SMF), Network Repository Function (NRF), and so on, with User
Equipment (e.g., UE 308), and creates specific trust boundaries
across multiple service providers using distributed blockchain
ledgers, as discussed in greater detail herein. Blockchain network
304 may represent an open source blockchain network or platform
such distributed ledgers, hyperledger Sawtooth, and the like.
[0035] With specific reference to FIG. 3A, schematic block diagram
301 illustrates a roaming architecture with a local breakout
scenario for a service based interface representation of SBA 132.
As shown, this roaming architecture 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 FIG.
3A 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.
[0036] As shown, the network entities that form SBA 132 include AMF
320, SMF 325, Network Slice Selection Function (NSSF) 330, Network
Exposure Function (NEF) 335v|335h, Network Repository Function
(NRF) 340v|340h, Policy Control Function (PCF) 345v|345h, and
Application Function (AF) 350. 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.
[0037] In general, UE 308 connects to RAN/Access Network (AN) 310
as well as AMF 320. 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 320 provides UE-based authentication,
authorization, mobility management, etc. SMF 325 is responsible for
session management, IP address allocation to UE(s), and traffic
management/selection of a User Plane Function (UPF) (e.g., UPF 315)
for proper routing/data transfer. If UE 308 has multiple sessions,
different SMFs may be allocated to each session for individual
management and/or different functionality per session. AF 350
generally provides information on packet flows to PCF 345v, which
is responsible for policy control in order to support Quality of
Service (QoS). Based on the information from AF 350, PCF 345v
determines policies about mobility and session management for
proper AMF/SMF operations. AUSF 355 stores authentication data for
UE 308, and UDM 360 stores subscription data for UE 308. Data
network 108 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.
[0038] FIG. 3B illustrates a schematic block diagram 302, showing a
reference point interface representation of SBA 132 (e.g., with a
local breakout scenario). Reference point representations often
help develop detailed call flows in a normative standardization,
which are illustrated in FIGS. 4A, 4B, and 5 (and described in
greater detail below). It should be noted, for sake of clarity,
certain network entities (e.g., NEF 335, NRF 340, etc.) are not
shown by schematic block diagram 302. However, it is appreciated
any of the illustrated network entities can interact with the
non-illustrated entities as appropriate.
[0039] As mentioned, the native blockchain platform shown in FIGS.
3A and 3B includes enterprise blockchain network 304, which
interconnects various blockchain service providers (SPs),
represented as Blockchain Authentication Function (BAF) entities
305a-305n, with various mobile network entities over blockchain
network interfaces BCx, BCy, and BCz. In general, this native
blockchain platform provides an additional and/or alternative
blockchain authentication procedure for registering UE, such as UE
308. Notably, this blockchain authentication procedure may be
represented by blockchain authentication process/services 244 (ref.
FIG. 2).
[0040] Continuing to refer to FIGS. 3A and 3B, RAN/Access Network
(AN) 310 broadcasts system information (e.g., PLMN-IDs) to various
UE(s), including UE 308. UE 308 receives the PLMN-ID from
RAN/Access Network (AN) 310 and, during its initial registration,
UE 308 indicates support for a complimentary (and/or substitute)
blockchain authentication procedure. For example, UE 308 can
indicate support for the blockchain authentication procedure in a
radio layer message (e.g., a Radio Resource Control (RRC) message)
sent to RAN/Access Network (AN) 310.
[0041] RAN/Access Network (AN) 310 receives the RRC messages from
UE 308 and selects an appropriate AMF 320 and/or redirects the RRC
messages to a new AMF as appropriate. Here, RAN/AN 310 can
determine the RRC message from UE 308 include an indication to
perform the blockchain authentication procedure (e.g., in an access
category) and selects AMF 320 and/or redirects to a new AMF based
on its capability to support the blockchain authentication
procedure.
[0042] As discussed in greater detail below, AMF 320 can perform
the blockchain authentication procedure by exchanging
authentication messages with one or more Blockchain Authentication
Function (BAF) entities (e.g., BAF(s) 305a-n) over blockchain
network interfaces BCx and/or BCy.
[0043] The blockchain authentication procedure generally refers to
authentication messages exchanged between one or more core NFs and
a BAF, which is exposed to the core NFs over the new blockchain
network interfaces. The authentication messages provide the BAF
with UE credentials and the BAF, in turn, compares the UE
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 if the UE
credentials match the UE credentials stored on the blockchain or
distributed ledger.
[0044] For example, FIGS. 4A and 4B provide signaling diagrams
showing different embodiments of the blockchain authentication
procedure. In particular, in one embodiment, AMF 320 may send
authentication messages to invoke/request that AUSF 355 perform
blockchain authentication, which causes AUSF 355 to authenticate UE
308 with BAF 305 over blockchain network interface BCx (e.g., ref
FIG. 4A), while in other embodiments, AMF 320 can directly
authenticate UE 308 with BAF 305 over blockchain network interface
BCy (e.g., ref. FIG. 4B), using for example, REST Application
Program Interface (API) messages.
[0045] In general, UE 308 may indicates support for the blockchain
authentication procedure to AMF 320 using RRC messages over RAN/AN
network interfaces (which are further transmitted to AMF 320)
and/or UE 308 may send a Non-Access Stratum (NAS) messages directly
to AMF 320 (e.g., over network interface N1), which NAS messages
indicate UE 308 supports/request the blockchain authentication
procedure. For these NAS layer messages, the indication can be
included directly in a NAS message (e.g., as payload data such as
registration type) and/or in follow-on request (e.g., follow-on
request data).
[0046] In addition, AMF 320 and/or AUSF 355 may still perform
conventional authentication processes, 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 355, selecting UDM 360, retrieving
vectors, e.g., credentials and/or encryption keys, from UDM 360,
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, while in
other embodiments, the blockchain authentication procedure can
replace existing authentication processes (e.g., if existing
authentication processes fail.
[0047] As mentioned, FIGS. 4A and 4B illustrate respective
schematic signaling diagrams 401/402 for the disclosed a blockchain
authentication procedure where AMF 320 invokes AUSF 355 in diagram
401, and AMF 320 directly authenticates UE 308 with BAF 305. 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 registration
procedures can vary based on initial registrations, mobility
registration updates, periodic registration updates, and so on.
FIGS. 4A and 4B illustrate an initial registration procedure in
accordance with embodiments of the disclosed blockchain
authentication procedure, however it is appreciated the call flows
may be modified based the type of UE registration.
[0048] Blockchain Registration Process Via AUSF
[0049] Referring now to FIG. 4A, schematic signaling diagram 401
begins at step 403, where UE 308 sends a registration request
message to RAN/AN 310. In one embodiment, the registration request
message can indicate UE 308 supports a blockchain authentication
procedure in, 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)).
TABLE-US-00001 RRC establishment Access identities Access
categories cause is set to 0 0 (=MT_acc) MT access 1 (=delay
tolerant) FFS 2 (=emergency) Emergency call 3 (=MO_sig) MO
signaling 4 (=MO MMTel voice) MO voice call 5 (=MO MMTel video) FFS
6 (=MO SMS and FFS SMSoIP) 7 (=MO_data) MO data 1 Any category
"High priority access" 2 Any category "High priority access" 11, 15
Any category "High priority access" 12, 13, 14, Any category "High
priority access" NOTE: See subclause 4.5.2, table 4.5.2.1 for use
of the access identities of 0, 1, 2, and 11-15.
[0050] Next, RAN/AN 310 selects an AMF--here, AMF 320--based on the
registration message. For example, RAN/AN 310 determines the
registration request message indicates UE 308 supports the
blockchain authentication procedure, and can select an appropriate
AMF that likewise supports such procedure. Alternatively, RAN/AN
310 can reject the blockchain authentication request, which causes
the UE to revert to exiting 3GPP behaviour.
[0051] At step 404, RAN/AN 310 sends a registration request message
to AMF 320. 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).
[0052] For example, the 5GS registration type information element
is provided below:
TABLE-US-00002 9.8.3.7.1: 5GS registration type information element
8 7 6 5 4 3 2 1 5GS registration type IEI FOR 5GS registration type
octet 1 value
TABLE-US-00003 9.8.3.7.1: 5GS registration type information element
5GS registration type value (octet 1) Bits 3 2 1 0 0 1 initial
registration 0 1 0 mobility registration updating 0 1 1 periodic
registration updating 1 1 0 emergency registration 1 1 1 reserved
All other values are unused and shall be interpreted as "initial
registration", if received by the network. Follow-On Request bit
(FOR) (octet 1) Bit 4 0 No follow-on request pending 1 Follow-on
request pending
[0053] In 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).
[0054] As discussed in greater detail below, the blockchain
authentication 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 320 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 320 may further perform the blockchain
authentication procedure as a complimentary or supplemental
process. However, as mentioned above, in some instances, AMF 320
may perform the blockchain authentication procedure and
register/attach UE 308 to the network even if the standard EAP-AKA
procedures fail (depending on policy/requirements).
[0055] Signaling diagram 401 continues to steps 406 and 408 where
UE 308 and AMF 320 exchange identity request/response messages.
Here, AMF 320 initiates a UE identity request at step 406 during an
initial registration, e.g., when AMF 320 is new to UE 308, and/or
when AMF 320 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 320 particularly initiates
authentication with UE 308 by sending an identity request message
at step 406 and, in response, UE 308 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 408.
[0056] In some embodiments, UE 308 returns additional parameters at
step 408 to indicate support for the blockchain authorization
procedure (e.g., in addition to or as an alternative to the above
discussed indications in 5GS registration type information). After
step 408, AMF 320 initiates UE authentication processes with an
AUSF and selects AUSF 355 based on, for example, SUCI/SUPI
information (described in 3GPP TS 23.501) and/or the indicated
support for the blockchain authorization procedure.
[0057] Steps 410-424 illustrate the blockchain authentication
procedure employed by AUSF 355 in conjunction with conventional
authentication calls (e.g., as specified by 3GPP TS 33.501) between
AMF 320, AUSF 355, and UDM 360. As described below, the ordering
and exchange messages represented by steps 410-424 reflect various
bi-lateral message exchanges.
[0058] In particular, step 410 provides optional
challenges/responses between AMF 320 and UE 308, which allow UE 308
to indicate support for the blockchain authorization procedure in
NAS messages sent to AMF 320 (e.g., over network interface N1).
[0059] At step 412, AMF 320 can invoke existing authentication
services by sending an authentication request message to AUSF 355.
In response, AUSF 355 checks that the requesting AMF in the serving
network is entitled to use the serving network and sends, at step
414, a corresponding authentication request message to UDM 360. UDM
360 generates and sends an authentication vector (e.g., security
keys, etc.) to AUSF 355, again at step 414.
[0060] AUSF 355 also exchanges EAP-Requests/AKA-Challenges with AMF
320, at step 416, which further solicit EAP challenges/responses
from UE 308, at step 418. As shown, the EAP challenges/responses
between UE 308 and AMF 320 can include NAS messages with blockchain
payload data to provide AMF 320 (and thus AUSF 355 at step 416)
relevant blockchain authentication information (e.g., UE 308
registration information with prior BAF entities, etc.) for
subsequent or secondary authentication with BAF 305 (e.g., step 424
discussed below). In accordance with existing authentication
protocols, and based on the EAP challenges/responses received by
AUSF 355 at step 416, AUSF 355 can complete UE authentication with
UDM 360 at step 414.
[0061] Collectively, the messages exchanged at steps 410-416 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 308, AMF 320, AUSF 355, and UDM
360, which protect/encrypt subsequent messages from UE 308.
[0062] Regardless of success/failure of UE authentication in steps
410, AMF 320 and AUSF 355 may further perform the blockchain
authentication 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.
[0063] Depending on policies and/or security requirements, AMF 320
may continue on to perform the blockchain authentication process
with AUSF 355. As mentioned above, AMF 320 can receive relevant
blockchain authentication information from UE 308 in the course of
exchanging authentication messages based on existing procedures, or
alternatively, UE 308 can send separate NAS messages to AMF 320
with the blockchain authentication information included in payload
data, such as shown at step 420. The blockchain authentication
information is used by AMF 320/AUSF 355 to authenticate UE 308 with
BAF 305. For example, the blockchain authentication information can
include a blockchain entity ID that corresponds to BAF 305 as well
as blockchain credentials, such as blockchain registration
information, blockchain subscription information, and so on.
Preferably, UE 308 registers and subscribes to BAF 305 (e.g., over
blockchain network interface BCz) to obtain the blockchain
authentication information. AMF 320 receives these NAS messages,
identifies the blockchain entity ID, and selects an appropriate BAF
(here, BAF 305) based on the blockchain entity ID.
[0064] AMF 320 further invokes AUSF 355, at step 422, to continue
the blockchain authentication procedure and authenticate UE 308
with BAF 305 using, for example, a Nausf service call over the N12
network interface. In this fashion, AMF 320 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 355.
[0065] AUSF 355 receives the API messages and exchanges, at step
424, blockchain authentication messages with BAF 305 over
blockchain network interface BCx. AUSF 355 further sends these
blockchain authentication messages to AMF 320 (e.g., blockchain
authentication confirmation, etc.) so AMF can complete the
blockchain authentication procedure. It is appreciated the
blockchain authentication procedure may require additional messages
to handle situations where BAF 305 is slow to respond, is
unavailable or out of service, and/or fails to confirm the UE
credentials. In these situations, AMF 320 may send temporary Ack
messages to UE 308 to provide additional processing time for BAF
305 to authenticate the UE credentials.
[0066] In sum, steps 420-424 represent blockchain authentication
operations where AMF 320 receives identifying information for the
BAF associated with UE 308 and selects BAF 305 based on the
identifying information (e.g., steps 420-422), and completes the
authentication transaction by acting as an agent of UE 308 since UE
308 may be considered a client of BAF 305 (e.g., steps 424).
Preferably, UE 308 previously registered and subscribed to BAF 305
over blockchain interface BCz.
[0067] Once UE 308 is successfully authenticated with the
blockchain authentication procedure, signaling diagram continues to
steps 430, 432, 436, and 438, which include messages to complete UE
308 registration in accordance with 3GPP TS 23.502 (e.g., UDM
selection/update, PCF selection, registration acceptance, and so
on).
[0068] In some embodiments of this disclosure, the blockchain
authentication procedure may also include an optional credit check
for UE 308, shown as a charging event at step 434. Notably, this
credit check represents a charging authorization procedure that can
be performed after UE 308 is authenticated with BAF 305 but before
AMF 320 completes registration and attaches UE 308 to the SBA
network.
[0069] In operation, PCF 345 manages mobility credentials for UE
308 and performs the credit authorization procedure with BAF 305 in
an authorization layer. The credit authorization procedure
determines if UE 308 (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 345 can use the credit authorization procedure to
determine virtual contract information (e.g., credit worthiness)
associated with UE 308, which can be shared with other network
entities/services (e.g., NFs) in SBA 132.
[0070] As mentioned above, steps 430, 432, 436, and 438 include
messages to complete UE 308 registration in accordance with 3GPP TS
23.502.
[0071] Blockchain Secondary Authentications Using AMF
[0072] In other embodiments of this disclosure, AMF 320 may
directly perform the blockchain authentication procedure with BAF
305 (e.g., after, for example, AMF 320 successfully obtains an
appropriate security context/acknowledgements from AUSF 355/UDM
360), which ensure encryption/integrity protection for messages
exchanged with UE 308.
[0073] In particular, signaling diagram 402 of FIG. 4B shows AMF
320 directly performing the blockchain authentication procedure
with BAF 305. Notably, signaling diagram 402 includes many of the
same steps or calls shown in signaling diagram 401, which are
discussed above.
[0074] In addition to the steps shown in signaling diagram 401,
signaling diagram 402 further provides steps 426 and 428, which
represent AMF 320 operations to directly exchange blockchain
authentication messages with BAF 305. In particular, at step 426,
UE 308 exchanges blockchain authentication information with AMF 320
using, for example, NAS messages that can include blockchain
payload data. The blockchain authentication information is used by
AMF 320 to authenticate UE 308 with BAF 305. As mentioned, the
blockchain authentication information can include a blockchain
entity ID that corresponds to BAF 305 as well as blockchain
credentials, such as blockchain registration information,
blockchain subscription information, and so on. AMF 320 receives
these NAS messages and selects an appropriate BAF (here, BAF 305)
based on the blockchain entity ID. AMF 320 further authenticates UE
308 with BAF 305 at step 428 and may receive an authentication
confirmation from BAF 305.
[0075] Steps 430, 432, 436, and 438 represent messages for
completing UE registration in accordance with 3GPP TS 23.502.
[0076] FIG. 5 illustrates an example simplified procedure 500 for
registering User Equipment (UE) in accordance with one or more
embodiments of the blockchain authentication procedure. Procedure
500 can represent operations of a blockchain authentication process
(e.g., blockchain authentication process/services 244) that may be
performed by one or more NF entities (e.g., NF/device 200) and can
include, for example, an AMF entity (AMF 320) and/or an AUSF entity
(AUSF 355).
[0077] Procedure 500 begins at step 505 and continues on to step
510 where, as discussed above, the AMF determines User Equipment
(UE) (e.g., UE 308) supports a blockchain authentication procedure.
For example, the AMF can determine the UE supports the blockchain
authentication procedure from a Radio Request Control message (RRC)
such as a registration request message and/or a Non-Access Stratum
message received from the UE (e.g., in a registration type field, a
NAS payload field, follow-on request data, etc.). Notably, in some
embodiments, the RAN/AN in communication with the UE may select the
AMF based on the indicated support for the blockchain
authentication procedure.
[0078] Procedure continues to step 515 where the AMF optionally
selects or invokes an Authentication Server Function (AUSF) entity
to perform the blockchain authentication procedure. As discussed
above, the AMF may directly communicate and authenticate the UE
with a Blockchain Authentication Function (BAF) entity (e.g, BAF
305), or it may invoke an AUSF to perform the blockchain
authentication procedure.
[0079] In step 520, the AMF receives blockchain credentials from
the UE. The blockchain credentials refer to blockchain
authentication information and can include blockchain
registration/subscription information. In some embodiments, the UE
receives the blockchain credentials from the BAF entity over a
blockchain network interface (e.g., BCz).
[0080] The AMF further determines, at step 525, the blockchain
credentials include a blockchain entity ID, and selects, at step
530, the BAF (e.g., BAF 305) for blockchain authentication based on
the same.
[0081] The AMF also exchanges authentication messages, at step 535
with the BAF. As mentioned, the AMF exchange the authentication
messages directly with the BAF (e.g., over a blockchain network
interface BCy or indirectly (e.g., through the AUSF entity, which
communicates with the BAF entity over a blockchain network
interface BCz). The AMF receives, at step 540, a blockchain
authentication confirmation from the BAF entity (again, either
directly or indirectly through the AUSF entity). Notably, in some
embodiments, the BAF entity may require additional processing time
to validate the UE's credentials. In these embodiments, the AMF may
send temporary Ack. messages to the UE to accommodate the
additional processing time.
[0082] The AMF can optionally invoke, at step 545, a Policy Control
Function (PCF) entity (e.g., PCF 345) to perform a credit
authorization procedure (e.g., in an authorization layer) for a
user associated with the UE. As mentioned above, the credit
authorization procedure can determine a scope of network services
(e.g., access or restrict) to be provided to the UE based on the
credit worthiness of the user. In some embodiments, this
information may be included as part of a virtual contract that can
be shared with various NFs. Next, the PCF can provide, at step 545,
the UE access to one or more network resources based on the credit
authorization procedure (e.g., credit worthiness of the user).
Finally, the AMF registers the UE at step 555.
[0083] Procedure subsequently ends at step 560, but may return
again to step 510 where the AMF determines another UE supports the
blockchain authentication procedure.
[0084] It should be noted that while certain steps within procedure
500 may be optional, and further, the steps shown in FIG. 5 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.
[0085] The 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.
[0086] While 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.
[0087] The 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.
* * * * *