Upload
others
View
6
Download
0
Embed Size (px)
Citation preview
CBRS Network Services Stage 2 and 3 Specification
CBRSA-TS-1002
V2.0.0
February 04, 2019
CBRS Alliance
3855 SW 153rd Drive
Beaverton, OR 97003
www.cbrsalliance.org
Copyright © 2019
CBRS Alliance
All Rights Reserved
LEGAL DISCLAIMERS AND NOTICES
THIS SPECIFICATION IS PROVIDED "AS IS," WITHOUT ANY REPRESENTATION OR
WARRANTY OF ANY KIND, EXPRESS, IMPLIED, OR STATUTORY; AND TO THE
MAXIMUM EXTENT PERMITTED BY LAW, CBRS ALLIANCE, AS WELL AS ITS
MEMBERS AND THEIR AFFILIATES, HEREBY DISCLAIM ANY AND ALL
REPRESENTATIONS AND WARRANTIES, INCLUDING WITHOUT LIMITATION ANY
WARRANTIES OF MERCHANTABILITY, TITLE, NON-INFRINGEMENT, FITNESS FOR A
PARTICULAR PURPOSE, ACCURACY, OR RELIABILITY, OR ARISING OUT OF ANY
ALLEGED COURSE OF PERFORMANCE, DEALING OR TRADE USAGE. ANY
PERMITTED USER OR IMPLEMENTER OF THIS SPECIFICATION ACCEPTS ALL RISKS
ASSOCIATED WITH THE USE OR INABILITY TO USE THIS SPECIFICATION.
THE PROVISION OR OTHER PERMITTED AVAILABILITY OF OR ACCESS TO THIS
SPECIFICATION DOES NOT GRANT ANY LICENSE UNDER ANY PATENT OR OTHER
INTELLECTUAL PROPERTY RIGHTS ("IPR"). FOR MORE INFORMATION REGARDING
IPR THAT MAY APPLY OR POTENTIAL AVAILABILITY OF LICENSES, PLEASE SEE
THE CBRS ALLIANCE IPR POLICY. CBRS ALLIANCE TAKES NO POSITION ON THE
VALIDITY OR SCOPE OF ANY PARTY'S CLAIMED IPR AND IS NOT RESPONSIBLE FOR
IDENTIFYING IPR.
TO THE MAXIMUM EXTENT PERMITTED BY LAW, UNDER NO CIRCUMSTANCES
WILL CBRS ALLIANCE, OR ANY OF ITS MEMBERS OR THEIR AFFILIATES, BE LIABLE
FOR DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, SPECIAL, EXEMPLARY,
PUNITIVE, OR OTHER FORM OF DAMAGES, EVEN IF SUCH DAMAGES ARE
FORESEEABLE OR IT HAS BEEN ADVISED OR HAS CONSTRUCTIVE KNOWLEDGE OF
THE POSSIBILITY OF SUCH DAMAGES, ARISING FROM THE USE OR INABILITY TO
USE THIS SPECIFICATION, INCLUDING WITHOUT LIMITATION ANY LOSS OF
REVENUE, ANTICIPATED PROFITS, OR BUSINESS, REGARDLESS OF WHETHER ANY
CLAIM TO SUCH DAMAGES SOUNDS IN CONTRACT, WARRANTY, TORT
(INCLUDING NEGLIGENCE AND STRICT LIABILITY), PRODUCT LIABILITY, OR
OTHER FORM OF ACTION.
CBRS Alliance
3855 SW 153rd Drive
Beaverton, OR 97003
www.cbrsalliance.org
Copyright © 2019
CBRS Alliance
All Rights Reserved
Table of Contents
1 SCOPE ................................................................................................................................................. 1
2 REFERENCES ..................................................................................................................................... 1
3 ABBREVIATIONS AND DEFINITIONS .......................................................................................... 4
3.1 ABBREVIATIONS .......................................................................................................................... 4
3.2 DEFINITIONS ................................................................................................................................ 6
4 VOID .................................................................................................................................................... 8
5 STAGE 2 ASPECTS ............................................................................................................................ 8
5.1 GENERAL ..................................................................................................................................... 8
5.2 ARCHITECTURE REFERENCE MODEL ........................................................................................... 8
5.2.1 Network Architecture – Use of CBRS band Without the CBRS-I .......................................... 10
5.2.2 Network Architecture – CBRS Network using CBRS-I and CBRS-NID ................................ 10
5.2.3 Network Architecture – Neutral Host Network and PSP ...................................................... 12
5.2.4 Network Architecture – Private Network using Neutral Host Network ................................ 13
5.2.5 Network Architecture – Hybrid Network............................................................................... 13
5.3 IDENTITIES ................................................................................................................................. 15
5.3.1 CBRS-I................................................................................................................................... 15
5.3.2 IMSI ....................................................................................................................................... 15
5.3.3 CBRS-NID ............................................................................................................................. 15
5.3.4 PSP-ID .................................................................................................................................. 16
5.3.5 ECGI ..................................................................................................................................... 16
5.3.6 GUMMEI............................................................................................................................... 17
5.3.7 TAI/TAC ................................................................................................................................ 17
5.3.8 CBRS Network-Name ............................................................................................................ 18
5.4 UE OPERATIONS ........................................................................................................................ 18
5.4.1 General .................................................................................................................................. 18
5.4.2 CBRS UE Profile ................................................................................................................... 19
5.4.3 Radio States of Mobile Devices ............................................................................................. 19
5.5 FUNCTIONS AND PROCEDURES .................................................................................................. 21
5.5.1 General .................................................................................................................................. 21
5.5.2 NHN Access Mode functions and procedures ....................................................................... 21
5.5.3 3GPP Access Mode (EPS-AKA) functions and procedures .................................................. 23
5.5.4 3GPP-based Access Mode (non-EPS-AKA) functions and procedures ................................ 23
6 STAGE 3 ASPECTS .......................................................................................................................... 27
6.1 GENERAL ................................................................................................................................... 27
6.2 STAGE 3 ASPECTS OF NHN ACCESS MODE ................................................................................. 27
6.2.1 General .................................................................................................................................. 27
6.2.2 RRC ....................................................................................................................................... 27
CBRS Alliance
3855 SW 153rd Drive
Beaverton, OR 97003
www.cbrsalliance.org
Copyright © 2019
CBRS Alliance
All Rights Reserved
6.2.3 STa interface ......................................................................................................................... 28
6.2.4 Extended Authentication for NHN Access Mode ................................................................... 29
6.3 STAGE 3 ASPECTS OF 3GPP ACCESS MODE (EPS-AKA) .......................................................... 29
6.4 STAGE 3 ASPECTS FOR 3GPP-BASED ACCESS MODE (NON-EPS-AKA) .................................... 29
6.4.1 Extended Authentication for 3GPP-based Access Mode (non-EPS-AKA) ............................ 29
6.4.2 EAP Authentication ............................................................................................................... 31
6.4.3 Downlink EAP authentication NAS Transport ...................................................................... 31
6.4.4 Uplink EAP authentication NAS Transport .......................................................................... 31
6.4.5 CB1a Interface ...................................................................................................................... 32
7 OTHER ASPECTS ............................................................................................................................ 32
7.1 CBRSA NHN KPIS ................................................................................................................... 32
APPENDICES (INFORMATIVE) ............................................................................................................. 33
APPENDIX A: OPERATIONAL CONSIDERATIONS ........................................................................... 33
A.1 PRIVATE NETWORK DEPLOYMENT ................................................................................................. 33
A.2 DEPLOYMENTS OF FIXED WIRELESS NETWORKS – GUIDELINES ..................................................... 34
A.2.1 Fixed Wireless Network deployed by a Service Provider Use Case ......................................... 34
A.2.2 Fixed Wireless Network deployed by NHN Operator Use Case ............................................... 37
APPENDIX B: DIAMETER SIGNALING CONTROLLER FOR AUTHENTICATION ....................... 39
B.1 INTRODUCTION ................................................................................................................................. 39
B.2 SCOPE ............................................................................................................................................... 39
B.3 AUTHENTICATION IN VISITED NETWORKS ....................................................................................... 39
B.4 ACCESS POINT NAME RESOLUTION FOR HOME ROUTED PDN CONNECTIONS ................................ 39
B.5 DIAMETER SIGNALING CONTROLLER (DSC) ................................................................................... 40
APPENDIX C: A NOTE ABOUT THIS DOCUMENT’S DEVELOPMENT .......................................... 45
APPENDIX D: REVISION HISTORY ...................................................................................................... 46
CBRS Alliance
3855 SW 153rd Drive
Beaverton, OR 97003
www.cbrsalliance.org
Copyright © 2019
CBRS Alliance
All Rights Reserved
LIST OF FIGURES
FIGURE 5.2.1-1: NETWORK ARCHITECTURE – USE OF CBRS BAND WITHOUT THE CBRS-I ..................... 10
FIGURE 5.2.2-1: NETWORK ARCHITECTURE – CBRS PRIVATE NETWORK USING A CBRS-I AND CBRS-
NID ..................................................................................................................................................... 11
FIGURE 5.2.3-1: NETWORK ARCHITECTURE – NEUTRAL HOST NETWORK AND PARTICIPATING SERVICE
PROVIDER ........................................................................................................................................... 12
FIGURE 5.2.4-1:NETWORK ARCHITECTURE – PRIVATE NETWORK USING NEUTRAL HOST NETWORK ...... 13
FIGURE 5.2.5-1: NETWORK ARCHITECTURE – HYBRID NETWORK ............................................................. 14
FIGURE 5.3.5-1: ECGI ................................................................................................................................. 17
FIGURE 5.3.6-1: GUMMEI .......................................................................................................................... 17
FIGURE 5.3.7-1: TAI/TAC........................................................................................................................... 18
FIGURE 5.5.4-1: NETWORK ARCHITECTURE FOR 3GPP-BASED ACCESS MODE (NON-EPS-AKA) – SINGLE
SUBSCRIPTION .................................................................................................................................... 24
FIGURE A.2.1.1-1: FIXED WIRELESS DEPLOYMENT BY SP – WITH TUNNEL .............................................. 34
FIGURE A.2.1.1-2: FIXED WIRELESS DEPLOYMENT BY SP – WITH TUNNEL (CALL FLOW) ....................... 35
FIGURE A.2.2-1: FIXED WIRELESS DEPLOYMENT BY NHN OPERATOR ..................................................... 37
FIGURE A.2.2-2: FIXED WIRELESS DEPLOYMENT BY NHN OPERATOR (CALL FLOW) .............................. 37
FIGURE B.5-1: DIAMETER SIGNALING ARCHITECTURE FOR IMS AND EPC WITH THE DIAMETER
SIGNALING CONTROLLER (DSC) FORMED WITH DRAS, DAS AND DEAS; BOTH PRE-EPC AND EPC
INTERFACES ARE LISTED, BUT ONLY INTERFACES S6A AND S9 ARE RELEVANT FOR THIS ANNEX. .... 41
FIGURE B.5-2: ILLUSTRATION OF THE ACTION OF A DIAMETER AGENT FOR ROUTING IMSI REQUESTS
FROM EXTERNAL NETWORKS; ONLY INTERFACES RELEVANT TO THE EPC ARE LISTED. ................... 42
LIST OF TABLES
TABLE 6-1: INTERPRETATION OF “BSSID-R12” VALUES ............................................................................. 28
TABLE 6-2: FEATURE BITS IN “SSID-R12” ................................................................................................... 28
TABLE B.5-1: MESSAGES HANDLED BY THE DA CORRESPONDING TO THE S6A INTERFACE [19] .............. 42
TABLE D-1 : CHANGE HISTORY .................................................................................................................. 46
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
1
1 Scope
This specification provides the stage 2 and stage 3 aspects of networks that uses CBRS band
(3550-3700 MHz) like Neutral Host Networks and Private/Public Networks.
This specification is based on Release 1 of the Stage 2 and Stage 3 MulteFire Alliance
specifications (e.g., MFA TS MF.202 [2], MFA TS 36.413 [9], MFA TS 24.301 [10]) and on
3GPP specifications.
The key words "required", "shall", "shall not", "should", "should not", "recommended", "may",
and "optional" in this document are to be interpreted as described in RFC-2119 [30].”
2 References
References are either specific (identified by date of publication, edition number, version number,
etc.) or non-specific. For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP, or
CBRS Alliance, or MulteFire Alliance document, a non-specific reference implicitly refers to the
latest version of that document in the same Release as the present document, or the specified
Release.
[1] 3GPP TR 21.905, Third Generation Partnership Project (3GPP). Vocabulary for 3GPP
Specifications, http://www.3gpp.org/, Release 14.
[2] MFA TS MF.202, MulteFire Alliance (MFA), Architecture for Neutral Host Network
Access Mode Stage 2, https://www.multefire.org/, Release 1.0.
[3] 3GPP TS 36.331, “Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification”, Release 14.
[4] 3GPP TS 23.402, “Architecture enhancements for non-3GPP accesses”,
http://www.3gpp.org/, Release 14.
[5] 3GPP TS 24.301, “Non-Access-Stratum (NAS) protocol for Evolved Packet System
(EPS)”, http://www.3gpp.org/, Release 14.
[6] 3GPP TS 32.426, “Telecommunication management; Performance Management (PM);
Performance measurements Evolved Packet Core (EPC) network”, http://www.3gpp.org/,
Release 14.
[7] 3GPP TS 32.432, “Performance measurement: File format definition”,
http://www.3gpp.org/, Release 14.
[8] 3GPP TS 32.455, “Telecommunication management; Key Performance Indicators (KPI)
for the Evolved Packet Core (EPC); Definitions”, http://www.3gpp.org/, Release 14.
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
2
[9] MFA TS 36.413, MulteFire Alliance (MFA), Architecture for Neutral Host Network
Access Mode Stage 2, https://www.multefire.org/, Release 1.0.
[10] MFA TS 24.301, MulteFire Alliance (MFA), Architecture for Neutral Host Network
Access Mode Stage 2, https://www.multefire.org/, Release 1.0.
[11] 3GPP TS 36.413, “Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1
Application Protocol (S1AP)”, http://www.3gpp.org/, Release 14.
[12] 3GPP TS 33.401, “3GPP System Architecture Evolution (SAE); Security architecture”,
http://www.3gpp.org/, Release 14.
[13] MFA TS 33.401, MulteFire Alliance (MFA), Architecture for Neutral Host Network
Access Mode Stage 2, https://www.multefire.org/, Release 1.0.
[14] 3GPP TS 23.401, “3GPP System Architecture Evolution (SAE); Security architecture”,
http://www.3gpp.org/, Release 14.
[15] CBRSA-TS-1001-V2.0, “CBRS Network Services Use Cases and Requirements”,
Release 2.0.
[16] 3GPP TS 23.003, “Numbering, addressing and identification”, http://www.3gpp.org/,
Release 14.
[17] 3GPP TS 36.300, “Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2”,
http://www.3gpp.org/, Release 14.
[18] CBRSA-TS-1003-V2.0 “CBRSA – Extended Subscriber Authentication Technical
Specifications”, Release 2.0.
[19] 3GPP TS 29.272 Third Generation Partnership Project (3GPP). Technical Specification
Group Core Network and Terminals; Evolved Packet System (EPS); Mobility Management
Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on
Diameter protocol, Release 14.
[20] 3GPP TS 29.274, Third Generation Partnership Project (3GPP). Technical Specification
Group Core Network and Terminals; 3GPP Evolved Packet System (EPS); Evolved
General Packet Radio Service (GPRS); Tunneling Protocol for Control plane (GTPv2-C),
Release 14.
[21] 3GPP TS 31.102, Third Generation Partnership Project (3GPP). Technical Specification
Group Core Network and Terminals; Characteristics of the Universal Subscriber Identity
Module (USIM) application, Release 15.
[22] 3GPP TS 23.203, Third Generation Partnership Project (3GPP). Technical Specification
Group Services and System Aspects; Policy and charging control architecture, Release 15.
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
3
[23] 3GPP TS 29.212, Third Generation Partnership Project (3GPP). Technical Specification
Group Core Network and Terminals; Policy and Charging Control (PCC); Reference
points, Release 15.
[24] 3GPP TS 29.213, Third Generation Partnership Project (3GPP). Technical Specification
Group Core Network and Terminals; Policy and Charging Control signaling flows and
Quality of Service (QoS) parameter mapping Release 15.
[25] MFA TS MF.301, MulteFire Alliance (MFA), MulteFire Subscription Management
Stage 3, Release 1.0.
[26] IEEE Standards Association. Guidelines for Use of Extended Unique Identifier (EUI),
Organizationally Unique Identifier (OUI), and Company ID (CID)
https://standards.ieee.org/develop/regauth/tut/eui.pdf.
[27] CBRSA-TR-0100-V1.0, “CBRS Alliance Identifier Guidelines for Shared HNI”,
Release 2.0.
[28] ATIS IOC, International Mobile Subscriber Identity (IMSI) Assignment and Management
Guidelines for Shared HNI for CBRS Range,
http://www.atis.org/01_committ_forums/ioc/Docs/IMSI-CBRS-Guidelines.pdf.
[29] ATIS IOC, IMSI Block Number (IBN) Assignment for a Shared HNI Application and
Related Forms Package, http://www.atis.org/01_committ_forums/ioc/Docs/IMSI-CBRS-
Guidelines-AnnexA.pdf.
[30] IETF RFC 2119, Key words for use in RFCs to Indicate Requirement Levels, March 1997,
https://tools.ietf.org/html/rfc2119.
[31] IETF RFC 4072, Diameter Extensible Authentication Protocol (EAP) Application,
https://tools.ietf.org/html/rfc4072.
[32] IETF RFC 3579, RADIUS (Remote Authentication Dial In User Service) Support For
Extensible Authentication Protocol (EAP), https://tools.ietf.org/html/rfc3579.
[33] 3GPP TS 23.122, Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in
idle mode, Release 14.
[34] 3GPP TS 36.304, Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment
(UE) procedures in idle mode, Release 14.
[35] 3GPP TS 23.060, “3rd Generation Partnership Project; Technical Specification Group
Services and System Aspects; General Packet Radio Service (GPRS); Service description;
Stage 2”, Release 14.
[36] 3GPP TS 29.303, “3rd Generation Partnership Project; Technical Specification Group Core
Network and Terminals; Domain Name System Procedures; Stage 3”, Release 14.
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
4
[37] J. Ewert, L. Norrell, and S. Yamen, “Diameter Signaling Controller in Next-generation
Networks,” in Ericsson Review, 2012 at https://www.ericsson.com/en/ericsson-
technology-review/archive/2012/diameter-signaling-controller-in-next-generation-
signaling-networks.
[38] IETF RFC 3588, Diameter Base Protocol, Available at: http://www.ietf.org/rfc/rfc3588.txt.
[39] GSMA IR.34, “Guidelines for IPX Provider networks (Previously Inter Service Provider
IP Backbone Guidelines)”, Version 14.0, Aug. 2018.
[40] IETF RFC 5448, Improved Extensible Authentication Protocol Method for 3rd Generation
Authentication and Key Agreement (EAP-AKA'), Available at:
https://tools.ietf.org/html/rfc5448.
[41] 3GPP TS 33.402, “3rd Generation Partnership Project; Technical Specification Group
Services and System Aspects; 3GPP System Architecture Evolution (SAE); Security
aspects of non-3GPP accesses”, Release 14.
3 Abbreviations and Definitions
3.1 Abbreviations
AAA Authentication, authorization and accounting
AKA Authentication and Key Agreement
APN Access Point Name
APN-OI APN-Operator Identifier
AVP Attribute-Value Pair
CBRS Citizens Broadband Radio Service
CBRS-I CBRS Identifier
CBRS-NID CBRS Network Identifier
CBRSA CBRS Alliance
CBSD CBRS Device
CSG Closed Subscriber Group
DA Diameter Agent
DCCA Diameter Credit Control Application
DEA Diameter Edge Agent
DRA Diameter Routing Agent
DSC Diameter Signaling Controller
EMM EPS Mobility Management
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
5
EPC Evolved Packet Core
ePCO Extended Protocol Configuration Options
ePDG Evolved Packet Data Gateway
EPS Evolved Packet System
eSIM Embedded SIM
ESM EPS Session Management
E-UTRAN Evolved UMTS Terrestrial Radio Access Network
FQDN Fully Qualified Domain Name
GPRS General Packet Radio Service
GRX GPRS Roaming Exchange
GTP GPRS Tunneling Protocol
GUTI Globally Unique Temporary Identifier
HNI Home Network Identifier [MCC+MNC]
HSS Home Subscriber Server
IANA International Assigned Numbers Authority
IBN IMSI Block Number
IMSI International Mobile Subscriber Identity
IPX International Protocol Exchange
ME Mobile Equipment
MF MulteFire
MFA MulteFire Alliance
MME Mobility Management Entity
MNO Mobile Network Operator
MSO Multiple System Operator
NAS Non-Access-Stratum
NH Neutral Host
NHN Neutral Host Network
OID Organization Identifier
PCO Protocol Configuration Options
PCRF Policy and Charging Rules Function
PDN Packet Data Network
P-GW Packet-Gateway
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
6
PLMN Public Land Mobile Network
PLMN-ID Public Land Mobile Network Identifier
PSP Participating Service Provider
PSP-ID PSP Identifier
RAB Radio Access Bearer
RADIUS Remote Authentication Dial In User Service
RAN Radio Access Network
RG Residential Gateway
SIM Subscriber Identity Module
S-GW Serving-Gateway
SHNI Shared HNI
SPR Subscription Profile Repository
TAU Tracking Area Update
UDR User Data Repository
UE User Equipment
UICC Universal Integrated Circuit Card
USIM Universal Subscriber Identity Module
VoLTE Voice over LTE
3.2 Definitions
3GPP Access Mode A UE operational mode supporting the functions and procedures
(EPS-AKA) specified by 3GPP using the 3GPP defined EPS-AKA
authentication as described in 3GPP TS 33.401 [12].
That is, 3GPP Access Mode (EPS-AKA) is the normal UE operation
per 3GPP specifications, including the use of EPS-AKA or
EPS-AKA’[40, 41] for authentication.
3GPP-based Access Mode An operational mode supported by a UE that performs
(non-EPS-AKA) authentication without the use of EPS-AKA, and that in all other
aspects supports the functions and procedures specified by 3GPP.
That is, 3GPP-based Access Mode (non-EPS-AKA) is the UE
operation per 3GPP specifications, except that a non-EPS-AKA
method is used for authentication. This allows the authentication of
the UE without a USIM.
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
7
CBRS-I CBRS-I or CBRS-Identifier is a PLMN-ID that is broadcast in SIB1
in a CBRS Network. Using the policy pre-provisioned at the UE,
the UE may use CBRS-I and possibly CBRS-NID to recognize the
CBRS Network as NHN or a network supporting 3GPP/3GPP-based
Access Mode. SHNI is one such CBRS-I.
CBRSA NHN NHN adapted from the MulteFire Alliance (MFA) Release 1.0
specifications for neutral host deployment as described in section
5.5.2 of this specification.
HNI HNI is the Home Network Identifier. It is the combination of 3-digit
Mobile Country Code and 3-digit Mobile Network Code. In the US,
HNI is allocated to MNOs by the IMSI Oversight Council (IOC) of
ATIS.
Mobile Equipment (ME) Mobile Equipment is the portion of the user’s equipment that does
not include a USIM or eSIM.
Mobility Management Entity’ The MME’ is a 3GPP LTE MME that is extended to support an
(MME’) interface to a AAA for EAP authentication methods.
Neutral Host Network A network deployed and operated by an NH operator, who may also
be an independent entity, a MNO or a MSO, where the network
resources are being shared by multiple wireless services providers.
NHN Access Mode Operational mode between the UE and the network whereby
communication is based on the NHN functions and procedures
adapted from the MulteFire Alliance (MFA) Release 1.0
specifications for neutral host deployment as described in section
5.5.2. The NHN referred in this definition is CBRSA NHN.
SHNI An HNI designated by ATIS IOC [28] for CBRS operation that is
recognized by CBRS systems as shared. The first such assignment
is 315-010.
Private CBRS Network A Private CBRS Network provides services to subscribers or
connected devices authorized by the provider of the network.
Services could be provided exclusively to the network’s own
subscribers, and the network may be isolated from other networks.
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
8
Private Network A Private Network is a restricted secured CBRS network that
provides services to subscribers (e.g. employees, machines and
other devices) authorized by the Private Network Operator.
Private Network Operator A Private Network Operator is one that operates a private network,
and provide services to authorized users (i.e., subscribers) and
devices that are registered within that Private Network.
Public Network A Public Network provides telecommunications services to devices
that are associated with subscriptions from the operator of the CBRS
network, or its roaming partners. Any member of the public can be
a subscriber of such a network.
SHNI Network A network based on CBRS Alliance specifications that uses a
Shared HNI as the CBRS-I.
Supplemental CBRS-I A non-SHNI PLMN-ID that is used as CBRS-I.
4 Void
5 Stage 2 Aspects
5.1 General
The stage 2 aspects cover CBRS deployments based on CBRSA NHN Access Mode, 3GPP Access
Mode (EPS-AKA) and 3GPP-based Access Mode (non-EPS-AKA). The corresponding key stage
2 baseline specifications are:
- MulteFire Alliance Technical Specification MFA TS MF.202 [2] and
- 3GPP Technical Specification 3GPP TS 23.401 [14].
The modifications compared with [2] and [14] are described in this document.
5.2 Architecture Reference Model
Reference model for network architecture is depicted in sections 5.2.1 through 5.2.5. The network
elements and reference points associated with CBRSA NHN EPC architecture are as in section 5
of MFA TS MF.202 [2]. The network elements and reference points associated with 3GPP EPC
architecture are as in 3GPP TS 23.401 [14].
The interface shown as “AAA” in [2] is named “cbAAA” in this specification. It provides the
functions necessary for authentication and authorization between the CBRSA NHN Core and the
non-3GPP AAA.
Some highlights of the architecture are discussed below:
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
9
- The architecture enables deploying:
o Public Network (RAN + Core) operating in 3GPP Access Mode (EPS-AKA) to serve
CBRS devices that are equipped with a USIM based subscription;
o Private Network (RAN + Core) operating in 3GPP Access Mode (EPS-AKA) to serve
CBRS devices that are equipped with a USIM based subscription associated with a
Private CBRS network;
o CBRSA NHN (RAN + Core) operating in NHN Access Mode to serve CBRSA
NHN-capable CBRS devices that are equipped with a USIM based subscription
associated with a Participating Service Provider(s);
o Private CBRS network (RAN + Core) operating in NHN Access Mode to serve
CBRSA NHN-capable devices that are equipped with a USIM based subscription or a
certificate-based subscription associated with a Participating Service Provider (PSP).
o CBRS Network operating in 3GPP-based Access Mode (non-EPS-AKA) to serve
CBRS devices equipped with non-USIM based subscription.
- The architecture also enables the use of a common shared CBRS RAN which serves a NHN
Access Mode core network or/and multiple 3GPP Access Mode (EPS-AKA) and 3GPP-based
Access Mode (non-EPS-AKA) core networks.
- The architecture enables the CBRSA NHN to operate as a trusted non-3GPP Access Network
and/or untrusted non-3GPP Access Network for UEs associated with PSPs.
o In trusted mode, a CBRSA NHN uses the STa-N interface (as defined in MFA
TS MF.202 [2]) for UE authentication and enables one or more simultaneous home
routed PDN connections between the UE and the PSP’s PDN-GW using the S2a
interface. If the subscriber’s home operator allows, the CBRSA NHN may provide
additional PDN connections for local breakout of data traffic. Legal Intercept is not
specified for local breakout.
o In untrusted mode, a CBRSA NHN uses the SWa-N interface (as defined in MFA
TS MF.202 [2]) for UE authentication. In this mode, all PDN connections use local
breakout of data traffic. Legal Intercept is not specified in the untrusted case.
▪ In untrusted mode, a UE with a USIM based subscription can establish a secure
IPsec tunnel (i.e., SWu discussed in 3GPP TS 23.402 [4]) with its service
provider’s ePDG using the subscription and receive the service provider’s
services via the SWu interface.
- The architecture enables NHN Access Mode authentication using local or remote AAA
servers depending on which AAA server the UE credentials are associated with.
Note: The architecture has no impact on the support of traditional roaming between SPs.
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
10
5.2.1 Network Architecture – Use of CBRS band Without the CBRS-I
Figure 5.2.1-1 shows the architecture for a CBRS network with a standard 3GPP EPC using a
PLMN-ID other than CBRS-I and with the RAN using the CBRS band. The UE is accessing the
network using 3GPP Access Mode (EPS-AKA). This network architecture may be used for both
Public Networks and Private Networks.
SP1 EPC, using 3GPP EPC
architecture using a non-CBRS-I
value as PLMN-ID
SP1 3GPP UE- With SP1's PLMN-ID in USIM
LTE Radio
SP1 USIM based credentials
CBRS RAN
eNodeBeNodeB
CBRS RAN
eNodeBeNodeBBroadcasts • SP1 PLMN-ID
Figure 5.2.1-1: Network Architecture – Use of CBRS band Without the CBRS-I
5.2.2 Network Architecture – CBRS Network using CBRS-I and CBRS-NID
5.2.2.1 CBRS Private Network using CBRS-I and CBRS-NID
Figure 5.2.2-1 shows the architecture for a CBRS network with a standard 3GPP EPC using a
CBRS-I value and a CBRS-NID. This architecture supports both open and closed access to the
private network. The UE must be configured with CBRS-I and may optionally be configured with
CBRS-NID, for example to support closed access. The UE is accessing this network using 3GPP
Access Mode (EPS-AKA).
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
11
Private EPC using 3GPP EPC architecture using a CBRS-I
value as PLMN-ID
Local Services
Internet
SGi
Private 3GPP UE- With a CBRS-I value as PLMN-ID and private network’s CBRS-NID in USIM
LTE Radio
CBRS RAN
eNodeBeNodeB
CBRS RAN
eNodeBeNodeB
Private USIM-based credentials
SGi
Broadcasts • CBRS-I as PLMN-ID in SIB1• CBRS-NID in SIB1
Figure 5.2.2-1: Network Architecture – CBRS Private Network using a CBRS-I and CBRS-NID
Note: Any Private Network Operator may enter into business agreements with other
Network Operators thereby extending the Private Network capabilities to
admit subscribers belonging to other Networks. Via such business agreements,
it may also be possible for Private Network subscribers to attach into other
Networks.
5.2.2.2 CBRS Public Network using CBRS-I and CBRS-NID
The network architecture shown in Figure 5.2.2-1 may also be used for Public Network using
CBRS-I.
CBRS Private or Public Network can prevent unauthorized UEs from attempting to attach to the
network by deploying the network as a closed network (Closed Subscriber Group) using
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
12
CBRS-NID.
5.2.3 Network Architecture – Neutral Host Network and PSP
Figure 5.2.3-1 shows the architecture for a Neutral Host Network using a CBRS-I value and a
CBRS-NID. The UE is accessing the network using NHN Access Mode. The yellow line
illustrates the data plane path between the UE and the ePDG belonging to SP2, which can be used
to access the service provider’s services if the Neutral Host Network is considered untrusted by
SP2.
Figure 5.2.3-1: Network Architecture – Neutral Host Network and Participating Service Provider
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
13
5.2.4 Network Architecture – Private Network using Neutral Host Network
Figure 5.2.4-1 shows the architecture for a Private Network based on the Neutral Host Network
architecture using a CBRS-I value and a CBRS-NID. The UE is accessing the network using NHN
Access Mode.
Figure 5.2.4-1:Network Architecture – Private Network using Neutral Host Network
5.2.5 Network Architecture – Hybrid Network
Figure 5.2.5-1 shows the architecture of a hybrid network. A hybrid network can be built on any
combination of the architectures described in sections 5.2.1 through 5.2.4.
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
14
SP2 EPC, using 3GPP EPC architecture
Private EPC using 3GPP EPC architecture using a CBRS-I
value as PLMN-IDSP1 EPC, using 3GPP EPC
architecture using a non-CBRS-I
value as PLMN-ID
SP1 3GPP UE- With SP1's PLMN-ID in USIM
EPC using NHN EPC architecture
Non-3GPP AAA
3GPP AAA
HSS
NH-MMENH-GW
Local AAA/Proxy
SGi
cbAAA
STa-N/SWa-N
LTE Radio
SP1 USIM based credentials
S2a
PDN GW
Local Services
Internet
SGi
Private 3GPP UE- With a CBRS-I value as PLMN-ID and private network’s CBRS-NID in USIM
LTE Radio
SP2 NHN-capable UE- With SP2's PLMN-ID in USIM
LTE Radio
Private NHN-capable UE- Configured with CBRS-I, CBRS-NID, and private network’s PSP-ID
LTE Radio
CBRS RAN
eNodeBeNodeB
CBRS RAN
eNodeBeNodeB
Private USIM/Certificate/Username-
password based credentials
Private USIM-based credentials
SP2 USIM based credentials
3GPP AAA
HSS
SWxSTa
SGi
Broadcasts • SP1 PLMN-ID and CBRS-I in SIB1• CBRS-NID in SIB1• PSP-IDs for SP2 and Private
Network in SIB17
SGi
ePDG
S2b
Figure 5.2.5-1: Network Architecture – Hybrid Network
The S1 interface to a Private EPC using the 3GPP EPC architecture shown in Figure 5.2.5-1 is
the same as the 3GPP defined S1 interface if the PLMN-ID associated with the EPC is not used
by any other EPC connected to the CBRS RAN. Otherwise (i.e., when a private 3GPP EPC and a
CBRSA NHN EPC are both associated with the same CBRS-I), the architecture above is realized
using a dual-mode EPC (supporting 3GPP EPC mode and CBRSA NHN EPC mode) and a single
interface from the CBRS network’s RAN to the dual-mode EPC. The dual-mode EPC can function
as a private 3GPP EPC and as a CBRSA NHN EPC. Entities in the dual-mode EPC perform
corresponding 3GPP and CBRSA NHN functions. For instance, the MME/NH-MME in a
dual-mode EPC determines if the UE is accessing the network using NHN Access Mode upon
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
15
detecting a special IMSI (i.e., an IMSI composed of a CBRS-I value followed by 9 digits
containing the value zero), using 3GPP-based Access Mode (non- EPS-AKA) or 3GPP Access
Mode (EPS-AKA).
5.3 Identities
5.3.1 CBRS-I
CBRS-I is a PLMN-ID and the value is a Shared HNI1 or an Operator-specific
PLMN-ID allocated by the US IMSI Administrator. An Operator-specific PLMN-ID used as a
CBRS-I is called Supplemental CBRS-I. The same UE and network procedures and functions
apply to all CBRS-I values (i.e., an SHNI or a PLMN-ID configured as a supplemental CBRS-I
by a service provider). A CBRS-I is broadcast in SIB1 as an entry in the plmn-IdentityList. If a
CBRS-I is broadcast, then the corresponding CBRS-NID and CBRS Network Name may also be
broadcast.
5.3.2 IMSI
When using an SHNI the IMSI is formed from the 3-digit MCC, 3-digit MNC, 4 digit IBN (IMSI
Block Number) and 5-digit UIN (User Identity Number). The operator is responsible for ensuring
uniqueness of the IMSIs by not assigning duplicate UINs. Further information is available in the
Shared HNI IMSI Guidelines [28] and the IBN application and other forms [29].
5.3.3 CBRS-NID
CBRS-NID is the identity of the CBRS LTE Network. The CBRS-NID may identify a single
venue (e.g. a stadium) or a collection of venues (e.g., a chain of fast food restaurants).
• CBRS-NID is associated with the CBRS-I and is broadcast in the csg-Identity field of SIB1
(see section 6.2.2). If SHNI is used as the CBRS-I value, then CBRS-NID is unique for all
SHNIs (current and future).
• CBSDs using the same combination of CBRS-I and CBRS-NID must support the same list
of PSPs.
• Length of CBRS-NID applicable for networks broadcasting CBRS Alliance CBRS-I is
27 bits
• CBRS Network Operators using SHNI and complying to this specification, shall request
an assignment of CBRS-NID by CBRSA to ensure uniqueness of CBRS-NID.
• Broadcasting CBRS-NID by the CBSD is optional for all architectures independent of the
use of SHNI or PLMN-ID configured as supplementary CBRS-I, except for the Neutral
Host Architecture. The csg-Indication field can be set to TRUE or FALSE.
1 The IMSI Administrator manages the IMSI resource using guidelines [28] and forms [29]
developed by ATIS IOC.
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
16
• In a deployment using Network Architecture - Neutral Host and PSP, as in section 5.2.3,
the CBSD shall broadcast the CBRS-NID and set the csg-Indication field to FALSE in
SIB1. Configuration of the CBRS-NID in UE is optional.
• Any deployment, independent of the architecture, that seeks to close access to users using
Closed Subscriber Group functionality, shall broadcast the CBRS-NID and set the
csg-Indication field to be TRUE.
5.3.4 PSP-ID
PSP-ID is an identity of a participating service provider that provides services via a CBRSA NHN.
The following types of PSP-IDs are supported:
• PLMN based PSP-ID: a PLMN-ID [1] of the PSP. A SHNI shall not be used as PSP-ID.
• OID based PSP-ID: an OUI-24/MA-L identifier [26]. The OUI-24/MA-L identifier can be
obtained from the IEEE Registration Authority.
• Short-form based PSP-ID: a PSP-ID calculated from an Organization Identifier or Domain
Name of the PSP as described in section 5.7.1 of [2]. Short-form based PSP-ID is not
guaranteed to be unique, which can cause NHN access problems if the short-form based
PSP-ID collides with another PSP-ID. However even in the event of PSP-ID collision, NHN
access problems can be prevented by ensuring that the NHN has a unique Tracking Area
Identity (TAI) relative to any neighboring networks [27].
PSP-IDs of length 24 bits and short-form PSP IDs are broadcast in SIB17 by re-using the
wlan-OffloadInfoPerPLMN-List-r12 for the CBRS-I PLMN value as described in section 6.2.2.
The components in the CBRSA NHN EPC and the CBRS RAN shall be provisioned with the list
of PSP Identities under NHN Access Mode. A PSP may or may not support S2a. Support for S2a
interface is indicated to the UE in the PSP information that is broadcast in SIB17. Pre-provisioned
policy in the UE can guide the UE to utilize this indication. For example, there may be a policy
to select the PSP only if S2a interface is supported.
5.3.5 ECGI
Each LTE cell in a Network complying to this specification is identified by a globally unique
ECGI (RAN-Share-005 [15]), composed of the PLMN-ID, a 20-bit Macro eNB ID and an
additional 8 bits [11]. CBRS Network Operators using SHNI and complying to this specification,
shall request an assignment of Macro eNB ID by CBRSA to ensure ECGI uniqueness. The size
and configuration of the network will dictate the quantity of Macro IDs required (e.g., one per
eNodeB). The network operator can then identify up to 256 cells using the remaining 8 bits2.
2 In these figures, ‘d’ is used to signify a decimal digit and ‘b’ a binary digit.
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
17
Figure 5.3.5-1: ECGI
5.3.6 GUMMEI
As pointed out in section 5.7.2 of [2], an NH-MME/MME serving a UE attached using a CBRS-
I shall form the GUMMEI per [16] using the CBRS-I as the source of the MCC and MNC (size
is per 3GPP specifications). The MMEI used to create the GUMMEI is formed per [16] using the
MME Group ID (16 bits) and MME Code (8 bits) assigned to the NH-MME/MME. The GUTI is
formed per [16] from the GUMMEI and the M-TMSI (32 bits) assigned by the NH-MME/MME.
CBRS Network Operators using SHNI and complying to this specification, shall request an
assignment of MMEGI by CBRSA to ensure uniqueness of GUMMEI. The network may then
identify up to 256 MMEs per MMEGI using the MMEC.
Figure 5.3.6-1: GUMMEI
5.3.7 TAI/TAC
The Tracking Area Identity (TAI) is used to coordinate between neighboring CBRS LTE systems.
When using a Shared HNI, operators need to coordinate the TAI. The TAI is composed of the
HNI plus a 16-bit TAC (Tracking Area Code).
If a UE is rejected when presenting a TAI to the network, the UE might not attempt to access any
network broadcasting that TAI for a period of time (e.g. several minutes; see section 5.3.7 of MFA
TS 24.301[10]). Therefore, it is important that TAC codes (the only unique part of the TAI within
a Shared HNI, i.e. SHNI) are coordinated. In situations where coordination is necessary, it can be
done by neighboring CBRS operators. No coordination with MNOs is necessary, because they
use a TAI based on their own distinct HNI (not SHNI).
The Tracking Area Code is assigned by the operator, not by the CBRS Alliance, and needs to be
locally unique (i.e. not used by any other nearby network broadcasting SHNI). The full TAI format
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
18
is SHNI (6d/24b) + TAC (16b). The CBRS Alliance recommends the following method to define
6 TAC codes that will produce TAI codes that will not conflict with any other SHNI:
1. Network using the same method: The first TAC is the numeric value of the network’s
assigned IBN3 encoded as a 16-bit binary integer.
2. This code plus 10,000.
3. This code plus 20,000.
4. This code plus 30,000.
5. This code plus 40,000.
6. This code plus 50,000.
For example, for the IBN code 1234, the six TAC values will be 01234, 11234, 21234, 31234,
41234 and 51234. The highest possible code is 59999, smaller than the highest 16-bit value of
65535.
Figure 5.3.7-1: TAI/TAC
5.3.8 CBRS Network-Name
CBRS Network-Name is a meaningful name of the CBRSA NHN/Private Network to be presented
to the end user when doing manual network selection and when UE is attached to a CBRSA
NHN/Private Network. CBRS Network-Name is a 48-character string and is broadcast using the
SIB9 field hnb-Name. The presence of CBRS-I indicates to the UE that hnb-Name is to be
interpreted as CBRS Network-Name.
5.4 UE Operations
5.4.1 General
A UE can have one or more subscriptions and can support one or more CBRS-Profiles. Each
CBRS-Profile defines a certain functionality. In such cases, the UE is configured with policies
that define the UE behavior in a CBRS network. One such policy can be mapping of access mode
to the relevant CBRS-Profile and a subscription. The following sections provide a high-level
summary of the radio states for the UEs supporting various CBRS-Profiles. The radio states of
UE supporting multiple CBRS-Profile depends on the CBRS-Profile that the UE uses in a given
network.
3 Note that the IBN is usually encoded as BCD, in which case 9999 would be binary 1001 1001 1001 1001. However, the TAC should
be encoded as a binary integer, so 9999 would be binary 0010 0111 0000 1111.
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
19
5.4.2 CBRS UE Profile
This section defines different capabilities of the UE into CBRS Profiles4. A UE can support one
or more of these profiles. Refer to section 5 of [15] for more details on various CBRS UE profiles.
5.4.3 Radio States of Mobile Devices
5.4.3.1 CBRS-Profile I
Since CBRS-Profile I is a normal LTE UE with CBRS band support, there are two radio states:
• camped on SP access network (RRC Idle)
• connected on SP access network (RRC Connected)
5.4.3.2 CBRS-Profile I-A
This is a normal LTE UE with the capability to support 3GPP-based Access Mode (non-EPS-
AKA). Such a device has two radio states:
• camped on SP access network (RRC Idle)
• connected on SP access network (RRC Connected)
5.4.3.3 CBRS-Profile II
All PDN connections are established over 3GPP access, for example the Internet and IMS PDN
connections, are assigned to the access network on which the device is EMM Registered. A
CBRS-Profile II based device has the following mutually exclusive main radio states:
• camped on SP access network (RRC Idle)
• connected on SP access network (RRC Connected)
• camped on CBRSA NHN access network (RRC Idle)
• connected on CBRSA NHN access network (RRC Connected)
5.4.3.4 CBRS-Profile III
For a device capable of being simultaneously registered to two access networks (e.g., SP and
CBRSA NHN), different PDN connections may be assigned to different access networks. In
accordance with 3GPP specifications, mobile-originated or network-originated data for a PDN
connection is routed over the corresponding access network. The assignment of PDN connections
to access networks is governed by policies provisioned in the UE and/or SP network. For example,
the device may implement switching logic such that the IMS PDN connection (for VoLTE)
remains on the SP access network whenever possible.
A device based on CBRS-Profile III can optionally support CBRS-Profile 1-A. If the device
supports CBRS-Profile 1-A, then such a device can attach to SP Network using 3GPP Access
Mode (EPS-AKA) and 3GPP-based Access Mode (non-EPS-AKA).
4 CBRS UE profiles are implementation options for UE manufacturers and are not signaled to the network.
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
20
While registered to two access networks, a CBRS-Profile III based device has the following
mutually exclusive main radio states:
• camped on SP Network (RRC Idle), camped on CBRSA NHN (RRC Idle)
• camped on SP Network (RRC Idle), connected on CBRSA NHN (RRC Connected)
• connected on SP Network (RRC Connected), camped on CBRSA NHN (RRC Idle)
- This is an optional state.
• Not camped on SP Network, camped on CBRSA NHN (RRC Idle)
• Not camped on SP Network, connected on CBRSA NHN (RRC Connected)
A CBRS-Profile III based device can receive paging messages on both access networks, with the
limitations such as the one described below:
A CBRS-Profile III based device may be RRC Connected on only one access network at a time.
Conflicts can occur; for example, the device may receive a paging message for the IMS PDN
connection on the SP access network indicating an incoming VoLTE call, while the device is in
RRC Connected state on the CBRSA NHN for the Internet PDN connection. An implementation-
dependent policy resolves such conflicts, for example by switching to RRC Connected on the SP
access network and causing an interruption in service for the Internet PDN connection.
5.4.3.5 CBRS-Profile IV
A CBRS-Profile IV based device has dual uplink/downlink radio chains and a full LTE state
machine for both access networks.
5.4.3.6 CBRS-Profile V
A CBRS-Profile V based device has a single LTE transmit radio, has multiple subscriptions and
the ability to choose the subscription for specific services. A CBRS-Profile V based UE has the
ability to set up an SWu tunnel via the EMM Registered Access Network to obtain services using
the other subscription.
A device based on CBRS-Profile V can optionally support CBRS-Profile 1-A. If the device
supports CBRS-Profile 1-A, then such a device can attach to SP Network using 3GPP Access
Mode (EPS-AKA) and 3GPP-based Access Mode (non-EPS-AKA).
A CBRS-Profile V based device has the following mutually exclusive main radio states:
• camped on SP access network (RRC Idle)
• connected on SP access network (RRC Connected)
- All PDN services obtained from SP network
• camped on CBRS access network (RRC Idle)
• connected on CBRS access network (RRC Connected)
- SWu established with SP network to obtain certain services that are provisioned
to use SP network
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
21
5.5 Functions and Procedures
5.5.1 General
Functions and procedures applicable to NHN Access Mode described in section 5.5.2 are
supported. On the network side, they are realized primarily using CBRS RAN and EPC using
CBRSA NHN EPC architecture depicted in section 5.2.3 (Figure 5.2.3-1).
3GPP procedures applicable to 3GPP Access Mode (EPS-AKA) described in section 5.5.3 are
supported. On the network side, they are realized primarily by CBRS RAN and EPC using 3GPP
EPC architecture depicted in section 5.2.1 (Figure 5.2.1-1) or section 5.2.2 (Figure 5.2.2-1).
Functions and procedures applicable to 3GPP-based Access Mode described in section 5.5.4 are
supported. On the network side, they are realized primarily using CBRS RAN and EPC using
3GPP EPC architecture depicted in section 5.2.2 (Figure 5.2.2-1), with
enhancements/modifications that are described in section 5.5.4.1.
Operational considerations for Private Network deployments using 3GPP EPS Architecture are
discussed in Appendix A.1.
MME selection is carried out as specified in 3GPP TS 36.331 [13]. When connecting to a cell in
CBRS RAN broadcasting multiple PLMN-Identities, a UE indicates the PLMN-Identity of the
EPC that it wants to attach to and the cell selects an EPC connected to it based on the indication.
This also applies to the case when using a dual-mode EPC discussed in section 5.2.5.
5.5.2 NHN Access Mode functions and procedures
5.5.2.1 General
The following terminology differences exist between the terminology of the MulteFire Alliance
and the terminology of the CBRS Alliance.
o MFA TS MF.202 term “MulteFire cell” or “MF cell” is interpreted as “CBRS cell”
o MFA TS MF.202 term “MulteFire RAN” is interpreted as “CBRS RAN”
o MFA TS MF.202 term “MulteFire network” is interpreted as “CBRS network”
o MFA TS MF.202 term “MulteFire AP” is interpreted as “CBRS eNB”
o MFA TS MF.202 term “MulteFire UE” is interpreted as “CBRS UE”
o MFA TS MF.202 term “NHAMI” is interpreted as “CBRS-I”
o MFA TS MF.202 term “NHN-ID” is interpreted as “CBRS-NID”, with differences as
noted in section 5.3.3.
All functions and procedures specified in [2] are supported except for the following:
o Online Sign-up (OSU) and broadcast of indication for support of OSU,
o Locally administered CBRS-NIDs,
o CBRSA NHN service discovery,
o Access service Authorization.
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
22
5.5.2.2 Modifications to MulteFire Features
This specification explicitly uses the following technical aspects that are different from [2].
• Network Discovery and Selection: A UE discovers CBRSA NHN by scanning CBRS
frequency band for networks broadcasting a pre-provisioned CBRS-I as a PLMN-Identity in
SIB1.
o The following aspects are common with [2]
▪ A CBRSA NHN-capable UE using a USIM based subscription may select a
CBRS-network (and attach to the network using NHN procedures) when the
network broadcasts a PSP-ID in SIB17 which identifies the service provider
that provisioned the credentials/subscription information into the UE. The
PSP-IDs may be the Home PLMN (HPLMN) ID or an equivalent HPLMN-ID
stored in the USIM.
▪ A CBRSA NHN-capable UE using a non-USIM based subscription may select
a CBRS-network (and access the network using CBRSA NHN procedures) if
the network broadcasts a PSP-ID associated with the subscription. In this
scenario, PSP-IDs may be an OID of the service provider or a short form-based
identity of service provider.
• Mobility in RRC Idle: Mobility between two CBRS networks with different CBRS-NIDs or
CBRS-Is in RRC Idle mode relies on policies configured in the UE and may not rely on
network configured neighbor lists or thresholds. The UE uses the following procedure during
such mobility.
o Access attempts (Attach procedure, Service Request procedure, TAU procedure) by a
UE using 3GPP Access Mode (EPS-AKA) and with an IMSI not belonging to network
shall be rejected as specified in section 5.5.3.1.
o For mobility between cells broadcasting different CBRS-NIDs, 3GPP defined LTE
procedures apply, and in addition the UE shall perform a Tracking Area Update (TAU)
procedure after selecting or reselecting to the target cell. If the NH-MME associated
with the target cell does not recognize a GUTI provided by the UE, for example
because the source and target cells are connected to different core networks, the target
NH-MME should reject the TAU procedure with an appropriate cause. The UE could
then perform an Initial Attach procedure for the existing PDN connections.
o UE performs Initial Attach procedure when moving between two CBRS networks
broadcasting different CBRS-I values.
• The IMSI used in the Attach Request of the initial Attach procedure indicates the preferred
Access Mode for a UE to the appropriate EPC. An IMSI field containing a value comprised
of a CBRS-I value and 9 zeros is used to indicates preference for NHN Access Mode. Any
other IMSI indicates the UE’s preference for 3GPP Access Mode (EPS-AKA); however, an
operator can configure their network to perform non-EPS-AKA authentication for all or
specified sets of UEs.
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
23
5.5.3 3GPP Access Mode (EPS-AKA) functions and procedures
3GPP Access Mode (EPS-AKA) is supported by a UE supporting functions and procedures
specified by 3GPP using the 3GPP defined EPS-AKA authentication as defined in 3GPP TS
33.401[12]. That is, 3GPP Access Mode (EPS-AKA) is the normal UE operation per 3GPP
specifications, including the use of EPS-AKA for authentication.
5.5.3.1 Rejecting access attempts by a UE with IMSI not belonging to network using CBRS-I
The EMM cause used for ATTACH REJECT, TRACKING AREA UPDATE REJECT and
SERVICE REJECT by a CBRS network’s EPC identified by CBRS-I and connected to a hybrid
CSG RAN [17] shall be Cause #12 defined in 3GPP TS 24.301 [5], when the associated UE uses
an IMSI that does not belong to the network. Exceptions to this requirement include but are not
limited to:
• security attacks by the UE,
• the UE is determined to be stolen using ME identity check procedure (see section 5.3.10.5
of 3GPP TS 23.401 [14]),
• repeated unsuccessful access attempts by the UE,
• the UE causes excessive signaling.
Note: Use of other EMM cause values (e.g., Cause #3, Cause #8) can cause the UE to
suspend access to all networks broadcasting CBRS-I, including networks where the
UE’s USIM based subscription is accepted (see section 5.5.1.2.5 of 3GPP TS 24.301
[5]).
Note: When using the EMM Cause #12, TACs of nearby networks should be coordinated
to ensure that nearby networks do not use same TAC. When two nearby networks use
the same TAC, a UE belonging to one of the networks on receiving a reject from
other network with above cause code will temporarily not attempt access to its home
network.
A CBRS-Profile I UE can be enhanced so that it does not connect to a hybrid cell [17] to register
with an EPC identified by CBRS-I if the cell broadcasts a CBRS-NID that is not in the UE’s CSG
list. However, this requires that the lists are well maintained. If the lists are not well maintained,
the enhancement can result in the UE not connecting to its home network.
5.5.4 3GPP-based Access Mode (non-EPS-AKA) functions and procedures
3GPP-based Access Mode (non-EPS-AKA) is supported by a UE that performs authentication
without the use of EPS-AKA, and that in all other aspects supports the functions and procedures
specified by 3GPP. That is, 3GPP-based Access Mode (non-EPS-AKA) is the UE operation per
3GPP specifications, except that a non-EPS-AKA method is used for authentication. This allows
the authentication of the UE without a USIM.
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
24
5.5.4.1 3GPP-based Access Mode (non-EPS-AKA) - Single Subscription
Figure 5.5.4-1 shows the architecture for 3GPP-based Access Mode (non-EPS-AKA) where the
MME provides functionalities for authenticating subscribers via both EPS-AKA (for USIM-based
authentication) and extended mechanisms (for EAP-based authentication). The architecture
highlights5 the components and interfaces that are added to the network or impacted because of
the adding of extended authentication mechanisms.
Figure 5.5.4-1: Network Architecture for 3GPP-based Access Mode (non-EPS-AKA) – Single Subscription
Entities that support dual-mode EPC may perform the authentication corresponding to 3GPP and
3GPP-based supported modes. For instance, the MME in a dual-mode EPC determines if the UE
is accessing the network using standard 3GPP Access Mode (EPS-AKA) or 3GPP-based Access
Mode (non-EPS-AKA) upon detecting if a special configuration for the presented IMSI is
available on the MME (i.e., an IMSI that is associated with a special configuration in the MME
that triggers the use of extended authentication instead of the EPS-AKA one). Other mechanisms
to identify the authentication mode preferred by the device may be used.
The non-3GPP AAA Server may also act as a proxy AAA server when roaming across different
private networks is enabled. In this case, the MME shall be configured to recognize identities
associated with participating SPs and start the appropriate authentication mechanism based on the
configured Subscription Data.
For example, roaming across MSO’s private networks can be enabled by initiating the EAP
authentication procedure that is routed through the proxy to the UE’s home AAA Server. To
enable roaming when the UE’s home network does not support extended authentication (e.g., a
traditional 3GPP network), SPs shall use 3GPP-defined roaming mechanisms and USIM-based
credentials.
The non-3GPP AAA Server is connected to the MME via the CB1a interface. The CB1a interface
carries EAP messages over Diameter [31] or RADIUS [32] transport protocols.
5 Modified components with respect to 3GPP architecture are highlighted in red color.
U
E
Serving
Gateway PDN
Gateway
PCRF
HSS non-3GPP
AAA
E-UTRAN
S11 S10
S1-U LTE-Uu
S6a
S5
CB1a
IP Services
Gx Rx MME’
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
25
5.5.4.2 Network Architecture - Dual Subscriptions for 3GPP-based Access Mode (non-EPS-
AKA)
In case a UE is provisioned with multiple credentials (typically one USIM based and one, or more,
non-USIM based), the UE can subscribe to two different networks to access, for example,
different classes of services. Let’s assume that the first subscription is from SP1 and uses non-
USIM-based credentials while the second subscription is from SP2 and uses USIM-based
credentials. The UE may attach to SP1 by using the Extended Authentication method (as
configured in the SP1’s MME or MME’) by using the IMSI associated with SP1’s credentials for
data services and may attach to the SP2 by using the IMSI associated to the USIM based
credentials from SP2 for voice services.
5.5.4.3 Stage 2 Changes in 3GPP Specs for 3GPP-based Access Mode (non-EPS-AKA)
5.5.4.3.1 Attach Procedure
The attach procedure as defined in section 5.3.2.1 of 3GPP TS 23.401 [14] is modified in
Step 5a. In particular, when the presented identity is associated with non-USIM credentials, the
MME’ shall not request the authentication vector from the HSS and it shall initiate the EAP
authentication procedures as identified in this document.
5.5.4.3.2 Tracking Area Update Procedure
Step 6 in sections 5.3.3.1, 5.3.3.1A, and 5.3.3.2 of 3GPP TS 23.401 [14] are modified to use
Extended Authentication as defined in this document when the authentication procedure is
required (i.e., when the check on the TAU request message fails) and the identity in the request
message is associated with non-USIM credentials.
5.5.4.3.3 Service Request procedures
Step 3 in section 5.3.4.1 of 3GPP TS 23.401 [14] is modified to use Extended Authentication as
defined in this document when the security functions are performed, and the identity of the UE is
associated with non-USIM credentials.
5.5.4.3.4 Detach Procedures
UE, HSS and MME Initiated Detach procedures as specified by 3GPP are supported with 3GPP-
based Access Mode (non-EPS-AKA).
5.5.4.3.5 Handovers
Handover procedures specified in 3GPP specifications apply to 3GPP-based Access Mode (non-
EPS-AKA). See 23.401 [14] and 29.274 [20] for example handover requirements. Tracking Area
Updates that may require an authentication will use EAP based access rather than EPS-AKA. For
inter-MME handovers where the S10 interface is employed, the EPS Context as described in
3GPP 29.274 [20] Figure 8.38-5: EPS Security Context and Quadruplets is profiled for non-AKA
authentication. More specifically, quintuplets and quadruplets are not required to be present in the
EPS security context.
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
26
5.5.4.3.6 ME, USIM, eSIM and UICC Stage 2 considerations
The 3GPP-based Access Mode (non-EPS-AKA) separates the (1) user credentials, subscription
profiles and network parameters from (2) the UICC, eSIM or USIM. Therefore, the 3GPP-based
Access Mode (non-EPS-AKA) does not mandate the user device to include a USIM, eSIM or
UICC. The subscriber profile and other user or network parameters typically contained on the
USIM as defined in 3GPP 31.102 [21], and modified with non-AKA credentials, may be
configured onto the Mobile Equipment or ME (which refers to portion of the user’s equipment
that does not include a USIM or eSIM), an eSIM or a USIM. The method of configuring the
device, UICC, eSIM or USIM, and the exact data model used to accommodate non-AKA
credentials – with or without the use of an eSIM or UICC – is out of scope for this release of
CBRS Alliance specifications. The following aspects apply:
• PLMN and network parameters may be provisioned on the ME. For example, Idle Mode
related procedures as described in 23.122 [33] and 36.304 [34] may retrieve parameters
from the ME rather than the USIM.
• Certain 3GPP specifications, such as 23.122 [23], assume that certain services are restricted
to emergency procedures in the absence of a USIM or absence of a UICC. These
specifications need to be re-interpreted to apply when a subscription is not present on the
user device.
• Parameters defined in 3GPP 31.102 [21] plus non-AKA credentials may reside on a USIM,
eSIM or directly on the ME.
5.5.4.3.7 Policy
3GPP-based Access Mode (non-EPS-AKA) does not alter the relationships among the HSS, UDR,
SPR and PCRF within the 3GPP architecture. While the PCRF uses portions of the subscriber
profile for policy control, it does not, however, retrieve authentication parameters as the PCRF is
not included in subscriber authentication procedures. Therefore, there is no impact to the 3GPP
PCRF for 3GPP-based Access Mode (non-EPS-AKA) Mode. No changes are required in
applicable 3GPP specifications such as 3GPP 23.203 [22], 3GPP 29.212 [23], or 3GPP 29.213
[24].
5.5.4.3.8 Rejecting access attempts by a UE with IMSI not belonging to network using
CBRS-I
Access attempts (Attach procedure, Service Request procedure, TAU procedure) by a UE using
3GPP-based Access Mode (non-EPS-AKA) and with an IMSI not belonging to network shall be
rejected as specified in section 5.5.3.1.
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
27
6 Stage 3 Aspects
6.1 General
Stage 3 aspects for NHN Access Mode based on MFA NHN specifications are in section 6.2.
Stage 3 aspects for 3GPP Access Mode (EPS-AKA) based on 3GPP specifications are in
section 6.3. Stage 3 aspects for 3GPP-based Access Mode (non-EPS-AKA) are in section 6.4.
6.2 Stage 3 aspects of NHN access mode
6.2.1 General
In NHN Access Mode, the EPS shall comply to the 3GPP EPS stage 3 specifications, with the
following exceptions:
• Instead of 3GPP TS 36.413 (S1-AP) [11], the MFA TS 36.413 [9] shall be used.
• Instead of 3GPP TS 24.301 (NAS) [5], the MFA TS 24.301 [10] shall be used with the
following adaptations:
o If an NH-MME does not recognize a GUTI provided by a UE for Tracking Area
Update (TAU) procedure, the NH-MME should reject the TAU procedure with
cause value #9 (UE identity cannot be derived by the network) or #10 (Implicitly
detached) (see section A.1 in [5]).
• Instead of 3GPP TS 33.401 (Security) [12], the MFA TS 33.401 [13] shall be used.
• Modifications as outlined in the sub-sections 6.2.2 and 6.2.3.
6.2.2 RRC
The CBRS-I is broadcast in SIB1 as an entry in the plmn-IdentityList. In addition to being
configured with one or more of the CBRS-I values, the UE may be configured with supplemental
CBRS-I values. Such additional CBRS-I values may be used by large NHN operators who can
obtain their own CBRS-I value (PLMN-ID).
The following technical aspects are different from [3]:
• SIB1 field csg-Identity shall contain the CBRS-NID. Format of te field remains as specified
in [3]. Note that csg-Indication field can take any value as specified in [3].
• SIB9 field hnb-Name [3] may contain the CBRS Network-Name, consisting of a string of less
than or equal to 48 characters. The presence of CBRS-I indicates to the UE that
hnb-Name shall be interpreted as CBRS Network-Name.
• SIB17 shall be used for announcing PSP information in CBRSA NHN. PSP information shall
be appended in the WLAN-Id-List-r12 of the WLAN-OffloadInfoPerPLMN-r12
corresponding to the CBRS-I after the WLAN configuration (if WLAN configuration is
announced in the network). WLAN-OffloadConfigCommon-r12 shall not be present for PSP
Information.
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
28
o Each WLAN-Identifiers-r12 containing PSP information shall contain a multicast and
locally administered bssid-r12 value. This bssid-r12 shall be a fixed value as specified
in the table below and serve as an indication to the receiver that the information
present in the ssid-r12 shall be interpreted as a PSP-ID of the specified type.
Table 6-1: Interpretation of “bssid-r12” Values
Value of bssid-
r12
Interpretation by receiver
03:ff:ff:ff:ff:ff WLAN-Identifiers-r12 contains PLMN based PSP-ID
03:ff:ff:ff:ff:fe WLAN-Identifiers-r12 contains OID based PSP-ID
03:ff:ff:ff:ff:fd WLAN-Identifiers-r12 contains short-form based PSP-ID
o The ssid-r12 field (of length 32x8=256 bits) shall be interpreted as a sequence of PSP
Information entries. Each PSP Information entry is 28 bits and is composed of a 24-bit
PSP-ID followed by four feature bits. Reserved feature bits shall be set to zero by the
sender and ignored by the receiver. The meaning and purpose of the feature bits is as
follows: Table 6-2: Feature Bits in “ssid-r12”
B3 B2 B1 B0 (LSB)
PLMN based PSP
identities: PSP
supports S2a if bit
is set.
Reserved for other
types of PSP
identities.
Reserved Reserved Reserved
o For a WLAN-Identifiers-r12 entry with a PSP-information list, the hessid-r12 field is
reserved for future use and shall not be included by the sender and shall be ignored by
the receiver.
6.2.3 STa interface
The following technical aspects are different from [2]:
• The ANID AVP shall be created as the concatenation of the following:
o Constant character string “CBRS” shall be used as a prefix
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
29
o CBRS-NID represented as a 7-digit hexadecimal number using UTF-8 encoding of
the digits
6.2.4 Extended Authentication for NHN Access Mode
Stage 3 aspects of extended subscriber authentication (e.g. EAP-TLS, EAP-TTLS) for NHN
Access Mode are based on MFA NHN specifications [2] with modifications specified in [18].
6.3 Stage 3 aspects of 3GPP Access Mode (EPS-AKA)
In 3GPP Access Mode (EPS-AKA), Stage 3 functionality, procedures, messages and IEs shall
comply to the 3GPP EPS stage 3 specifications.
6.4 Stage 3 aspects for 3GPP-based Access Mode (non-EPS-AKA)
In 3GPP-based Access Mode (non-EPS-AKA), Stage 3 functionality, procedures, messages and
IEs shall comply to the 3GPP EPS stage 3 specifications, with the exception that authentication
is performed by a method other than EPS-AKA.
6.4.1 Extended Authentication for 3GPP-based Access Mode (non-EPS-AKA)
Stage 3 functionality, procedures, messages for 3GPP-based Access Mode (non-EPS-AKA) shall
comply to the 3GPP EPS stage 3 specifications with the following modifications:
• The EAP packets are transported between the UE and the MME’ by using two extended NAS
messages as defined in sections 6.4.3 and 6.4.4.
• When subscriber authentication is required, the MME’ shall use the Extended Authentication
procedures as defined in this document whenever the IMSI used for the authentication is
associated with non-USIM credentials.
Furthermore, the following sections provide detailed guidance about where the authentication
steps are updated when Extended Authentication is used instead of EPS-AKA procedures. Refer
CBRSA TS-1003 [18] for authentication details of 3GPP-based Access Mode (non-EPS-AKA).
6.4.1.1 Security Function
The Authentication and Key Agreement defined in section 5.3.10.2 of 3GPP TS 33.401 [12] is
modified to use the Extended Authentication between the UE and MME’ when the UE’s identity
is associated with non-USIM credentials.
6.4.1.2 Authentication and key agreement
Section 6.1.1 of 3GPP TS 33.401 [12] is not applicable for non-USIM based credentials. In
particular, the User Authentication Request and User Authentication Response shall not be used
for Extended Authentication.
Section 6.1.2 of 3GPP TS 33.401 [12] describes the procedures for retrieving the EPS
authentication vector when AKA is required. The Authentication data request shall not be used
by the MME’ for identities associated with Extended Authentication.
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
30
Section 6.1.4 of 3GPP TS 33.401 [12] describes the distribution of IMSI and authentication data
within one serving domain – when the GUTI presented in the TAU request from the user is
associated with Extended Authentication, the procedure is modified in step b) ii) where the MME’
shall not send unused EPS-authentication vectors in the response. Moreover, in this case, if
Authentication Vectors are carried in the Authentication data response, since they do not carry
valid authentication, they shall not be used.
Note: It is important that the receiving MME’ is correctly configured to identify, based on
the local IMSI configuration, when not to use the extended authentication vectors
that might be included in the Authentication data response.
6.4.1.3 EPS Key Hierarchy
The EPS key hierarchy as defined in section 6.2 of 3GPP TS 33.401 [12] is modified for
non-USIM credentials. In particular, the CK and IK values are not used in the UE and the HSS.
The KASME is directly derived from the Extended Authentication procedures on both the MME
and the non-3GPP AAA Server, as specified in sections 4.1, 6.2 and 6.3 in [18]. Moreover, the
KASME is delivered to the MME’ via the EAP-Success message as defined in this document.
6.4.1.4 Handling of EPS security contexts
Section 6.4 of 3GPP TS 33.401 [12] is modified as follows:
• Security contexts associated with Extended Authentication shall be deleted from the ME only
if the credentials that were used to create the EPS security context either is no longer available
(e.g., cannot be retrieved or it has been deleted from the ME’s storage) or is no longer valid
(e.g., the Subscriber Certificate is not valid).
• Any successful authentication for non-USIM credentials creates a partial native EPS security
context. This context shall overwrite any existing non-current EPS security context associated
with the used credentials.
• UEs shall support securely storing and processing subscriber credentials, security and
network contexts, and additional parameters (e.g., IMSI, multiple profiles, etc.)
independently from the credential type (i.e., AKA vs. non-AKA) or the specific storage used
(i.e., USIM or nonvolatile memory). Parameters may be stored in subscriber certificates - see
Appendix B or MFA MF 301 [25] (when EAP-TLS or EAP-TTLS with client authentication
is used), trusted execution environments if available, and/or crypto hardware may be used to
secure the data. The implementation of the storage and the data model used are left to UE
vendors.
• The UE shall follow best practices and use the available security control on the device to
protect the stored security contexts.
• Full native NAS security context associated with non-USIM credentials shall be stored in
nonvolatile memory of the ME.
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
31
6.4.1.5 E-UTRAN key setting during authentication
Section 7.2 of 3GPP TS 33.401 [12] is modified when Extended Authentication is used. In
particular, also in the case of successful completion of the EAP authentication procedures
associated with non-USIM credentials, a new KASME is generated and stored in the UE and MME’.
All procedures associated with KASME generated as a result of AKA runs also apply to KASME
generated as a result of successful EAP authentication.
6.4.2 EAP Authentication
The EAP authentication procedure as described in this document provides mutual authentication
between the UE and the network. When the authentication is successful, both parties agree on the
KASME from the key material generated during the execution of the supported EAP methods. The
UE and the network shall follow the authentication procedures as described in section 5.4.2MF1
of MFA MF 24.301 [5] with the modification introduced in this document.
The EAP authentication procedure applies to both NHN and 3GPP-based (non-EPS-AKA) access
modes.
For certificate-based authentication, UEs shall support the EAP-TLS method as described in [18].
For username and password authentication, UEs shall support the EAP-TTLS method as described
in [18].
Upon successful authentication, a partial native EPS security context is established in the UE and
the network – the KASME shall be stored in the EPS security contexts as described in MFA TS
33.401 [12] of both the network and in the volatile memory of the UE while attached to the
network.
The KASME is used to derive the EPS integrity protection and ciphering key hierarchy as described
in sections 5.12.3.3 and 5.12.3.4 of MF.202 [2].
6.4.3 Downlink EAP authentication NAS Transport
The DOWNLINK EAP AUTHENTICATION NAS TRANSPORT type messages are sent by the
network to the UE and carry the EAP packets in encapsulated format as defined in section
8.2.32MF1 of MFA TS 24.301 [10].
Note: As specified in section 5.4.2 MF1 of MFA TS 24.301[10] and in section 6.3 of MFA
TS 33.401[33], the eKSI is distributed to the UE in all downlink NAS messages
transporting EAP signaling (see Figure 5.4.2 MF1.2.1: EAP Authentication
Procedure)
6.4.4 Uplink EAP authentication NAS Transport
The UPLINK EAP AUTHENTICATION NAS TRANSPORT type messages are sent by the UE
to the network and carry the EAP packets in encapsulated format as defined in section 8.2.32MF2
of MFA TS 24.301 [10].
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
32
6.4.5 CB1a Interface
The CB1a interface is used to carry authentication messages (EAP) between the MME’ and the
non-3GPP AAA Server for subscriber authentication. The interface may support Diameter [31]
or RADIUS [32] transport protocols – the choice is left to the operator based on considerations
related to internal deployment strategies and vendor support availability for the specific protocol.
7 Other Aspects
7.1 CBRSA NHN KPIs
The minimal set of KPIs supported in a CBRSA NHN are:
• The number of Attempted EPS attach procedures [6, Sect. 4.1.1.1]
• The number of Successful EPS attach procedures [6, Sect. 4.1.1.2]
• The number of Failed EPS attach procedures [6, Sect. 4.1.1.3] per reject cause
• EPS Attach Success Rate [8, Sect. 5.1.1]
• Dedicated EPS Bearer Creation Success Rate [8, Sect. 5.1.2]
• Service Request Success Rate [8, Sect. 5.1.4]
The KPIs can be reported to the PSP according to the performance measurement file format
defined in [7]. The PSP and NHN operator agree on the end points and file transfer method (e.g.,
TCP) for the transfer of files containing performance measurements.
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
33
Appendices (Informative)
Appendix A: Operational Considerations
A.1 Private Network Deployment
The CBRS Alliance (CBRSA) will operationalize the following administrative tasks:
• Acquire a MNO independent PLMN-ID for CBRS Operators. Known as SHNI.
• Enable 3rd party entities using an SHNI to reserve CBRS-NID values from CBRS-NID
pool for that SHNI. These values will be broadcast in the csg-Identity field of SIB1.
• Enable users of an SHNI to obtain blocks of ECGI and GUMMEI codes to ensure
uniqueness.
An entity desiring to deploy a Private CBRS Network using an SHNI would reserve a CBRS-
NID, a block of GUMMEI, ECGI codes from CBRSA, and one or more IBN from the US IMSI
Administrator. The deploying entity would source private EPS infrastructure (CBRS RAN + EPC)
from infrastructure vendors. A Private Network would be configured to operate as a closed CSG
network broadcasting the SHNI and the csg-Identity equal to the reserved CBRS-NID.
It is recommended that Private Networks using an SHNI acquire unique blocks of ECGI and
GUMMEI codes from CBRSA to conform with CBRSA specifications, and because broadcasting
an SHNI may attract access attempts by foreign mobiles, and additionally, these identifiers may
be used in infrastructure outside the Private Network (such as in location and E911 applications).
It is also important to avoid network renumbering if, in the future, public traffic is allowed on the
network.
The Private Network may also use hybrid CSG [17] configuration if it is expected that the CSG
lists configured in the associated UEs are not well maintained. However, hybrid CSG [17]
configuration makes the network vulnerable to attempts from UEs of other networks (also see
section 5.5.3.1).
USIM providers can produce private USIMs (e.g., a UICC card containing credentials to a Private
Network) for the CBRSA CBRS-NID holders who have reserved IBNs based on an SHNI. These
private USIMs would be associated with a private authentication backend solution. The backend
solution could be a distributed local solution “AuC-on-a-USB-stick” or a cloud solution exposing
Web APIs for private USIM authentication. The deploying entity would acquire private USIMs
and an associated private USIM authentication solution for its approved IMSIs from a USIM
provider. USIMs would be used within the UEs and the CBRS-NID would be configured in the
UE CSG white list. Naturally the Private USIM authentication backend would authenticate only
the specific IMSI values and the matching SHNI secret credential (K) which are associated with
the accessed Private CBRS network as identified by the network’s csg-Identity.
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
34
For a Private Network using only a Private CBRSA NHN EPC (supporting only CBRS-Profile II
and above UEs), closed CSG configuration is strongly recommended as it will significantly reduce
the chances of UEs of other networks from attempting access to the network. CSG configuration
for a Private Network with CBRS-Profile I UEs is discussed in Appendix A.1.
A.2 Deployments of Fixed Wireless Networks – Guidelines
This section captures the guidelines for deploying Fixed Wireless Networks using CBRS as the
backhaul connectivity between the Customer Premise Equipment/Residential Gateway and the
Service Provider network.
These guidelines are based on the consideration that there shall be minimal or no modifications
necessary in the various network equipment’s involved in such deployments.
A.2.1 Fixed Wireless Network deployed by a Service Provider Use Case
A.2.1.1 Deployment Option 1 – With Tunnel
Figure A.2.1.1-1: Fixed Wireless Deployment by SP – With Tunnel
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
35
Figure A.2.1.1-2: Fixed Wireless Deployment by SP – With Tunnel (Call Flow)
The CPE comprises of an LTE Module with USIM that belongs to the Operator/Service Provider.
The CPE shall be able to attach to the CBRS network using the USIM. Once a bearer is
established, the CPE shall setup an inner tunnel with the Access Node of the Wireline network.
The inner tunnel may be a secure tunnel and the tunneling protocol shall be chosen according to
the services rendered (SP Policy). CPE may use any prevalent authentication mechanism using
802.1x protocol to establish the tunnel. Post establishing the tunnel, relevant
policies/configurations are pushed into the CPE. The CPE is now ready to offer service to end
users.
A.2.1.2 Deployment Option 2 – Without Tunnel
A.2.1.2-1: Fixed Wireless Deployment by SP – Without Tunnel
• FW Network provides the last mile access and operated same as Mobile Networks from
LTE perspective, but the CPE devices are expected to be fixed for a given location
CPE
EPC CBRS RAN
ISP-APN P-GW
HSS
RG
LTE Mdm Service
s
SGi SGW
MME
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
36
• The LTE modem (LTE-Modem) performs standard 3GPP compliant attach with the
service provider CBRS access and core networks
• CPE(UE) profile is maintained in HSS
• Residential Gateway (RG) is tunneled to ISP part of the provider using specific APN
• This procedure avoids GRE tunneling overhead on the air interface between eNB and
CBRS access network
• The same service provider can potentially own both CBRS access and core networks.
• The network as depicted shall provide both IP and non-IP access to the RG, as may be
desired. If non-IP access is needed to be provided to the RG, the profiles for the CPE/UE
shall be provisioned accordingly in the HSS and ePCO [20] optional shall be used to
provide non-IP access attributes
Figure A.2.1.2-2: Fixed Wireless Deployment by SP – Without Tunnel (Call Flow)
1. The LTE-Mdm component in the CPE device shall attach with the CBRS access network
and provider’s core network using the standard 3GPP procedures.
2. The provider can be potentially a multi service provider including but limited to fixed,
mobility and other services. The provider shall use a dedicated APN for serving the fixed
access ISP services. During the LTE attach process the CPE shall use this APN, the
subscriber profile for the CPE shall be configured accordingly in the HSS. There shall be
a designated P-GW for this APN in provider’s core network for the ISP services.
3. For IP access, the RG component of the can be provided with the IP configurable
parameters such as IP address, DNS server IP addresses etc. using the standard 3GPP
Protocol Configuration Options (PCO [20])
RG LTE-Modem
CBSD/eNB
EPC (MME/HSS/SG
P-GW For ISP APN
Edge Server
Attach and authentication per 3GPP specs
IP address shall be assigned to RG by P-GW designated for the ISP service in the provider network. PCO options could be used as need to pass additional information such as DHCP servers, etc.
APN used shall be specific to the ISP service of the provider
User plane traffic on over GTP no additional over head
User plane traffic on eRAB SGi UP traffic
If communication with RG requires non-IP protocol, then we can use ePCO to convey whatever parameters are critical for “start-up” of RG sub-system via 3GPP EPC. This will then be marked as non-IP APN in HSS.
5
2
3
4
1
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
37
4. If the RG is needed to have non-IP access, similar attach procedure as described in step
(2) above shall be followed. However, the subscriber profile for the CPE in HSS shall
indicate the non-IP access, also the non-IP access attributes can be sent to the UE/CPE
using the standard 3GPP ePCO [20] options
5. The data flow from the RG to the edge server in the service provider’s core shall flow
through the LTE-Mdm, CBSD/eNB and EPC following standard 3GPP LTE tunnels, no
additional tunneling is needed.
A.2.2 Fixed Wireless Network deployed by NHN Operator Use Case
Figure A.2.2-1: Fixed Wireless Deployment by NHN Operator
Figure A.2.2-2: Fixed Wireless Deployment by NHN Operator (Call Flow)
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
38
The CPE comprises of an LTE Module with USIM/certificates that belongs to the
Operator/Service Provider. The CPE shall attach to the CBRS network using the
USIM/certificates using 3GPP Access Mode (EPS-AKA) or NHN Access Mode (USIM or
certificates). The CBRSA NHN shall be able to communicate with the AAA server hosted by
service provider for authenticating the CPE using STa Interface (USIM authentication) or
cbAAA(non-USIM authentication). Once a bearer is established, the CPE shall setup an inner
tunnel with the Access Node of the Wireline network. The inner tunnel can be a secure tunnel and
the tunneling protocol will be chosen according to the services rendered (SP Policy). CPE may
use any prevalent authentication mechanism using 802.1x protocol to establish the tunnel. Post
establishing the tunnel, relevant policies are pushed into the CPE. The CPE is now ready to offer
service to end users. From the perspective of CBRSA NHN, all traffic emanating from the CPE
shall be locally broken out from CBRSA NHN-Core.
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
39
Appendix B: Diameter Signaling Controller for Authentication
B.1 Introduction
This Appendix describes the use of a Diameter Agent (DA) to support messaging on the S6a
(MME-HSS) interface with a future intent to consider messaging on the S9 (visited PCRF – home
PCRF) interface. The proposed mechanisms allow the DA to route messages from external
networks to the appropriate core network identified by the IMSI Block Number (IBN) that will
address those core networks. In the opposite direction, messages are aggregated and passed
through to the IPX Diameter provider on record.
B.2 Scope
The following roaming use cases are supported:
• Subscriber of one SHNI Network roams to another SHNI Network
• Subscriber of an SHNI Network roams into non-CBRS E-UTRAN or a CBRS E-UTRAN
that does not use SHNI.
This release addresses authentication for roaming to and from network using a SHNI. The support
for roaming is valid for data-only sessions and is typically applicable to those situations where
services offered by the visited network are accessed. In addition, there is limited support for
enabling home routed PDN connectivity.
Note: Home routing of IMS services is FFS.
B.3 Authentication in Visited Networks
When a UE with an IMSI constructed from an SHNI enters a visited network, the visited network
needs to access the UE’s Home Network HSS in order to authenticate the UE and allows the UE
to establish PDN services in the visited network. In order to accomplish this, a CBRSA Authorized
Diameter Signaling Controller (DSC) function will be needed to handle all messages concerning
the SHNI and route them to the correct Home Network HSS.
Note: CBRSA is assumed to take on the role of providing or authorizing the CBRSA
Authorized DSC function.
B.4 Access Point Name Resolution for Home Routed PDN Connections
When the visited network needs to resolve the Access Point Name (APN) name for a home routed
PDN connection, the APN-Fully Qualified Domain Name (APN-FQDN) for the P-GW will need
to be extended with an additional unique identity to resolve the ambiguity caused by the non-
unique PLMN-ID. For this purpose, the HSS can use the APN-OI Replacement field when
sending the user’s subscription information over the S6a interface to the visited MME [19]. The
APN-OI Replacement field is constructed as described in 3GPP TS 23.060 [35] and 3GPP TS
23.401 [14] while the FQDN derivation is detailed in 3GPP TS 23.003 [16]. The MME in the
visited network will use the received APN-OI Replacement field when constructing and resolving
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
40
the home P-GW domain name during P-GW selection when the visiting UE requests a new PDN
connection as follows.
The APN-OI replacement string will be added to the APN-FQDN:
APN-FQDN= <APN-NI>.mnc<MNC>.mcc<MCC>.gprs
where the APN-OI replacement field will replace mnc<MNC>.mcc<MCC>.gprs. The
format of APN-OI Replacement field should be:
<unique_identity>. mnc<MNC>.mcc<MCC>.gprs
For example, if an APN-OI replacement field is province1.mnc015.mcc234.gprs and
the APN-NI is “internet,” then the derived APN FQDN is
internet.province1.apn.epc.mnc015.mcc234.3gppnetwork.org
In the above, the APN-OI Replacement provides a string uniquely identifying the home
network. A recommendation is to include the IBN into the <unique_identity> field, so that
uniqueness can be assured.
Actual support of home-routing of Data sessions will have to use the S8 interface to establish
home-routing of the PDN connection based on the resolution of the APN-FQDN as shown above;
i.e., the APN-FQDN allows activation of the S8 interface so that sessions/bearers can be
established from the visited S-GW to the home P-GW. The procedures involved are as described
in the specifications 3GPP TS 29.303 [36] and 3GPP TS 29.274 [20].
Note:
• Home routing of IMS sessions is FFS.
• CBRSA may be required to take on the role of ensuring uniqueness of the home realm
and associated APN-FQDN with SHNIs.
B.5 Diameter Signaling Controller (DSC)
Portions of this section are excerpted from [37].
The Diameter protocol was first introduced for communication over the interfaces between the
IMS core and application servers, charging systems and HSS databases. In the EPC, the protocol
is used for policy control in addition to accessing user and charging information. The Diameter
signaling architecture for IMS and EPC is illustrated in Figure B.5-1.
The framework is a base protocol that defines the minimum mandatory set of AAA operations
[38]. The base protocol defines the message format, which comprises a header and a set of data
elements expressed as Attribute-Value Pairs (AVP). By expressing data as AVPs, applications
using the protocol can be extended in the future without having to modify existing source code or
data inputs; new information is simply added as a new AVP. The base protocol defines a set of
commands and AVPs that can deliver the minimum set of signaling functions, such as peer
discovery, capability exchange, proxying, loop detection and error handling. The base set of
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
41
operations can be extended by Diameter applications through the addition of new commands and
AVPs.
Diameter supports both SCTP and TCP transport protocols, and transport security is provided by
the TLS or IPsec protocol. Diameter is a peer-to-peer protocol that uses a request-answer
transaction format. A Diameter peer can be a client, a server or an agent – a Diameter Agent (DA).
Agents are positioned between clients and servers, and forward client requests to the appropriate
server.
The 3GPP Ro protocol is an example of how an existing Diameter application – the IETF specified
Diameter Credit Control Application (DCCA) – has been extended with additional AVPs to
support the exchange of charging information. However, most of the interfaces in 3GPP (S6a, Cx,
Rx, Sh and so on) have their own specific Diameter application. Each application requires a
specific ID, which is assigned by IANA; the S6a interface, for example, has the application ID
16777251 and is an interface that will carry the IMSI. For Diameter applications using reference
points Cx, Dx, S6a, S6d, Sh and Dh, the DSC uses the subscriber identity stored in an AVP in the
message.
Figure B.5-1: Diameter Signaling Architecture for IMS and EPC with the Diameter Signaling Controller
(DSC) formed with DRAs, DAs and DEAs; both pre-EPC and EPC interfaces are listed, but only interfaces
S6a and S9 are relevant for this annex.
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
42
Figure B.5-2: Illustration of the action of a Diameter Agent for routing IMSI requests from external
networks; only interfaces relevant to the EPC are listed.
Table B.5-1: Messages handled by the DA corresponding to the S6a Interface [19]
Mapping to
Diameter
AVP
Message Message
Direction
Purpose
User-Name Location Update MME->HSS update location information in the HSS
User-Name Cancel Location
Request
HSS->MME Delete a subscriber record
User-Name Purge UE
Request
MME->HSS Subscriber’s profile has been deleted
User-Name Insert Subscriber
Data Request
HSS->MME updating and/or requesting certain user
data in the MME
User-Name Delete
Subscriber Data
Request
MME->HSS remove some data of the HSS user profile
stored in the MME
User Name Authentication
Request
MME->HSS request Authentication Information from
the HSS
User-Id Reset Request HSS->MME to indicate to the MME that a failure has
occurred.
User-Name Notify Request MME->HSS Inform HSS that an inter-MME location
update has not occurred
A roaming CBRS subscriber of an SHNI Network will trigger IMSI requests from exterior
networks with Destination-Realm AVP containing a domain name constructed from the SHNI,
unless the visited MME already knows the address/name of the HSS for the user, and the
associated home network domain name. A DA at a location outside all core networks using the
SHNI is needed to serve as the host for Diameter signaling directed to this domain name.
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
43
A CBRSA Authorized DSC provides this service, effectively functioning as the Diameter Edge
Agent (DEA) for the SHNI. In addition, the CBRSA Authorized DSC maintains mappings of all
IBNs associated with the SHNI to the Diameter routing information of the corresponding SHNI
Network EPC.
IMSI requests from exterior networks are routed to the CBRSA Authorized DSC, which functions
as the DA in Figure B.5-2.6 The DA matches and recognizes the SHNI. It proceeds to execute a
rule to extract and process the IBN from the User-Name or User-Id AVP and updates the
Destination-Realm and Destination-Host AVPs in order to route the message to the correct SHNI
Network EPC. A peer DEA within the core network processes the Diameter messages received
and routes the message within the core network.
Note: Handling of messages in the reverse direction is FFS
Two interfaces are relevant: the S6a and the S9. The S6a interface pertains to messages between
the MME and HSS. The S9 interface handles two applications, the S9 application pertaining to
the installation of Policy Charging and Control (PCC) or QoS rules generated by the HPLMN into
the VPLMN, and the Rx application that is used to exchange service session information from the
V-PCRF to the H-PCRF.
This release includes a detailing of the relevant messages on the S6a interface in Table YY [19].
Two AVPs are handled, the User-Name and User-Id, and the optional Reset-ID functionality is
not supported due to its dependence on explicit encoding of the HNI without regard to other fields
in the IMSI.
Note: Support of the S9 interface is FFS.
EPS connections to the CBRSA Authorized DSC should be on a trusted connection. As the DSC
functionality is not explicitly specified as secure, there is a possible need for an external security
gateway establishing trust between the CBRSA Authorized DSC providing IMSI routing services
and each SHNI core network served by the DSC. A peer security gateway will terminate the
security association at the SHNI core network. For security, the credentials used for processing
Diameter messages are different from the credentials used in the SAS-CBSD interface. The
CBRSA Authorized DSC provider will establish procedures for secure transport of IMSI requests
between CBRS SHNI users and external networks.
Note: Operational aspects of DSC should be handled by the CBRSA Deployment and
Operations Working Group
6 The Internet Protocol (IP) Packet Exchange (IPX) Network is an Inter-Service Provider IP backbone that comprises the
interconnected networks of IPX providers and General Packet Radio Service (GPRS) Roaming Exchange (GRX) Providers
[39].
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
44
One CBRSA Authorized DSC is expected to serve all core networks using the same SHNI value.
If there are multiple SHNI values, there could be a separate CBRSA Authorized DSC for each
SHNI value.
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
45
Appendix C: A note about this document’s development
The normative material in this document was developed based on:
• CBRS Network Services Technical Report, CBRSA-TR-1001 V1.0.0.
• CBRS Network Services Private Networks Technical Report, CBRSA-TR-1002 V0.15.0.
The technical reports further contain more detailed discussions and recommendations for best
practices.
Note: The above technical reports may only be available to CBRS Alliance members.
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
46
Appendix D: Revision History
Table D-1 : Change History
Version Date Description
V1.0.0 2018-02-01 Release 1 of this Specification
V1.0.0
Rev 1
2018-02-08 Beginning of work for Release 2
Implemented NSTG-18-005
V1.0.0
Rev 2
2018-04-02 Implemented NSTG-18-031 (Moved UE Types to TS
1001)
V1.0.0
Rev2.3
2018-04-17 Implemented agreements on 3GPP Access Mode
terminology (EPS-AKA/non-EPS-AKA).
Added reference to CBRSA-TS-1003.
V1.0.0
Rev 3.0
2018-04-24 Changes agreed on-screen during the meeting on 2018-04-
23.
V1.0.0
Rev 4.0
2018-05-08 Implemented NSTG-18-048_r0_2018.04.26_Ruckus
Networks - American Tower_Technical_Fixed Wireless
Networks content for TS stage 2 & 3.docx - Added
contents from Fixed Wireless TR (NSTG-18-48)
V1.0.0
Rev 5.0
2018-06-18 Implemented NSTG-18-072_r0_2018.06.17_QC-FW
(work with IFAST)_Technical_NHN-ID length.docx –
updated section 5.5.2.1
V1.0.0
Rev 6.0
2018-07-30 • NHN prefixed with CBRSA (CBRSA NHN), UE Types
updates as UE Profiles
• Incorporated NSTG-18-096_r3 (NSTG-18-
090)_2018.07.25_CableLabs_Technical_CR to TS 1002
v3 per NSTG F2F.docx
V1.0.0
Rev 7.0
2018-08-22 • Incorporated CR approved in meeting held on 20 Aug
2018 (NSTG-18-109_r2_2018.08.06_Nokia_PSP-
ID_types_in_TS-1002.docx)
V1.0.0
Rev 8.0
2018-10-09 • Implemented NSTG-18-
110_r4_2018.08.10_IFAST_Identifier Uniqueness.docx
• Implemented NSTG-18-
126_r4_2018.09.26_Ericsson_Technical_DSC_Authenti
cation.docx
• Editorial Modifications – Paragraph alignment, section
numbering, font alignment, etc.
CBRS Alliance
CBRSA-TS-1002 V1.0.0 (Rev 13.0 moving to V2.0.0)
Copyright © 2019 CBRS Alliance | All Rights Reserved
47
V1.0.0
Rev 9.0
2018-10-10 • Editorial modification (SCH -> SHNI)
• Updated “Definitions” for SHNI and added “Definition”
for SHNI Network
V1.0.0
Rev 10.0
2018-10-10 • Ballot comments resolution. NSTG-18-146_r2_(NSTG-
18-143)_2018.11.24_Editor_TG_TS-1002 Ballot
Comments.docx
V1.0.0
Rev 11.0
2019-01-27 • Ballot Comment resolution. TWG-19-
211_2019.01.22_NSTG_Chair_TG_NSTG_TS 1002
Ballot Resolution.docx
• Implemented the following CRs
o NSTG-18-
150_r2_2018.12.03_Nokia_Technical_PrivateNe
twork.docx
o NSTG-18-
151_r1_2018.12.10_Nokia_Technical_PrivateNe
tworkOperator.docx
o NSTG-18-
154_r3_2018.12.10_Nokia_Technical_TS-1002
Ballot Comment 138.docx
o NSTG-18-157_r3_2018.12.17_Ruckus
Networks_Technical_Additional Text for
TS2.docx
o NSTG-19-006_r1_2019.01.22_Ruckus
Wireless_Technical_Text Proposal for TS 2
Comments 112 & 113.docx
V1.0.0
Rev 12.0
2019-02-04 • Updated minor edits received in email.
V1.0.0
Rev 13.0
2019-02-04 • Updated “last minute comment” on section 5.5.1 and
5.3.4