55
CBRS Network Services Stage 2 and 3 Specification CBRSA-TS-1002 V3.0.0 18 Feb 2020

CBRS Network Services Stage 2 and 3 Specification V3.0.0 ......5.5.4.2 3GPP-BASED ACCESS MODE (NON-EPS-AKA) - DUAL SUBSCRIPTION NETWORK ARCHITECTURE.....34 5.5.4.3 STAGE 2 EPS-AKA)

  • Upload
    others

  • View
    4

  • Download
    0

Embed Size (px)

Citation preview

  • CBRS Network Services Stage 2 and 3 Specification

    CBRSA-TS-1002

    V3.0.0

    18 Feb 2020

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    1

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    LEGAL NOTICES AND DISCLOSURES

    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. THIS DOCUMENT (INCLUDING THE INFORMATION CONTAINED HEREIN) IS PROVIDED AS A

    CONVENIENCE TO ITS READERS, DOES NOT CONSTITUTE LEGAL ADVICE, SHOULD NOT BE RELIED UPON

    FOR ANY LEGAL PURPOSE, AND IS SUBJECT TO REVISION OR REMOVAL AT ANY TIME WITHOUT NOTICE.

    THIS DOCUMENT IS PROVIDED ON AN “AS IS”, “AS AVAILABLE” AND “WITH ALL FAULTS” BASIS. CBRS

    ALLIANCE MAKES NO REPRESENTATION, WARRANTY, CONDITION OR GUARANTEE AS TO THE

    USEFULNESS, QUALITY, SUITABILITY, TRUTH, ACCURACY, OR COMPLETENESS OF THIS DOCUMENT OR

    ANY INFORMATION CONTAINED HEREIN. ANY PERSON THAT USES OR OTHERWISE RELIES IN ANY

    MANNER ON THE INFORMATION SET FORTH HEREIN DOES SO AT HIS OR HER SOLE RISK.

    IMPLEMENTATION OF A [NETWORK] AND/OR RELATED PRODUCTS OR SERVICES IS OFTEN COMPLEX

    AND HIGHLY REGULATED, REQUIRING COMPLIANCE WITH NUMEROUS LAWS, STATUTES, REGULATIONS

    AND OTHER LEGAL REQUIREMENTS (“LEGAL REQUIREMENTS”). AMONG OTHER THINGS, APPLICABLE

    LEGAL REQUIREMENTS MAY INCLUDE NETWORK OPERATOR REQUIREMENTS UNDER FEDERAL LAW,

    mailto:[email protected]://www.cbrsalliance.org/wp-content/uploads/2018/06/CBRS-Alliance_IPR-Policy_2016-06-301.pdf

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    2

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    REQUIREMENTS RELATING TO E-911, ETC. A DISCUSSION OF SUCH LEGAL REQUIREMENTS IS BEYOND

    THE SCOPE OF THIS DOCUMENT. ACCORDINGLY, NETWORK OPERATORS AND OTHERS INTERESTED IN

    IMPLEMENTING NETWORKS OR RELATED SOLUTIONS ARE STRONGLY ENCOURAGED TO CONSULT WITH

    APPROPRIATE LEGAL, TECHNICAL AND BUSINESS ADVISORS PRIOR TO MAKING ANY IMPLEMENTATION

    DECISIONS.

    © 2020 CBRS ALLIANCE. ALL RIGHTS RESERVED.

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    3

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    Table of Contents

    1. SCOPE .........................................................................................................................................8

    2. REFERENCES ................................................................................................................................8

    3. ABBREVIATIONS AND DEFINITIONS ........................................................................................11

    3.1 ABBREVIATIONS .................................................................................................................11

    3.2 DEFINITIONS .......................................................................................................................13

    4. VOID ..........................................................................................................................................14

    5. STAGE 2 ASPECTS ....................................................................................................................14

    5.1 GENERAL .............................................................................................................................14

    5.2 ARCHITECTURE REFERENCE MODEL ...................................................................................15

    5.2.1 NETWORK ARCHITECTURE – USE OF CBRS BAND WITHOUT THE CBRS-I ..................16

    5.2.2 NETWORK ARCHITECTURE – CBRS NETWORK USING CBRS-I AND CBRS-NID ..........17

    5.2.2.1 CBRS PRIVATE NETWORK USING CBRS-I AND CBRS-NID........................................17

    5.2.2.2 CBRS PUBLIC NETWORK USING CBRS-I AND CBRS-NID ..........................................18

    5.2.3 NETWORK ARCHITECTURE – NEUTRAL HOST NETWORK AND PSP............................18

    5.2.4 NETWORK ARCHITECTURE – PRIVATE NETWORK USING NEUTRAL HOST NETWORK

    20

    5.2.5 NETWORK ARCHITECTURE – HYBRID NETWORK .........................................................20

    5.2.6 NETWORK ARCHITECTURE – TRAFFIC LOCAL BREAKOUT ...........................................22

    5.2.6.1 VOID ............................................................................................................................23

    5.3 IDENTITIES ...........................................................................................................................23

    5.3.1 CBRS-I ..............................................................................................................................23

    5.3.2 IMSI ..................................................................................................................................24

    5.3.3 CBRS-NID .........................................................................................................................24

    5.3.4 PSP-ID ..............................................................................................................................24

    5.3.5 ECGI ................................................................................................................................25

    5.3.6 GUMMEI ..........................................................................................................................25

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    4

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    5.3.7 TAI/TAC ...........................................................................................................................26

    5.3.8 CBRS NETWORK NAME ..................................................................................................27

    5.4 UE OPERATIONS .................................................................................................................27

    5.4.1 GENERAL .........................................................................................................................27

    5.4.2 CBRS UE PROFILE ............................................................................................................27

    5.4.3 RADIO STATES OF MOBILE DEVICES .............................................................................28

    5.4.3.1 CBRS-PROFILE I............................................................................................................28

    5.4.3.2 CBRS-PROFILE I-A ........................................................................................................28

    5.4.3.3 CBRS-PROFILE II ...........................................................................................................28

    5.4.3.4 CBRS-PROFILE III ..........................................................................................................28

    5.4.3.5 CBRS-PROFILE IV .........................................................................................................29

    5.4.3.6 CBRS-PROFILE V ..........................................................................................................29

    5.5 FUNCTIONS AND PROCEDURES ........................................................................................30

    5.5.1 GENERAL .........................................................................................................................30

    5.5.2 FUNCTIONS AND PROCEDURES IN NHN ACCESS MODE ............................................30

    5.5.2.1 GENERAL......................................................................................................................30

    5.5.2.2 MODIFICATIONS TO MULTIFIRE FEATURES................................................................31

    5.5.3 FUNCTIONS AND PROCEDURES IN 3GPP ACCESS MODE (EPS-AKA) ........................32

    5.5.3.1 REJECTING ACCESS ATTEMPTS BY A UE WITH IMSI NOT BELONGING TO

    NETWORK USING CBRS-I .............................................................................................................32

    5.5.4 FUNCTIONS AND PROCEDURES IN 3GPP-BASED ACCESS MODE (EPS-AKA) ............33

    5.5.4.1 3GPP-BASED ACCESS MODE (NON-EPS-AKA) - SINGLE SUBSCRIPTION NETWORK

    ARCHITECTURE ...............................................................................................................................33

    5.5.4.2 3GPP-BASED ACCESS MODE (NON-EPS-AKA) - DUAL SUBSCRIPTION NETWORK

    ARCHITECTURE ...............................................................................................................................34

    5.5.4.3 STAGE 2 CHANGES IN 3GPP SPECS FOR 3GPP-BASED ACCESS MODE (NON-

    EPS-AKA) 34

    5.5.5 ROAMING SUPPORT ......................................................................................................36

    5.5.5.1 AUTHENTICATION OF AN SHNI SUBSCRIBER IN VISITED PLMN ..............................36

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    5

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    5.5.5.2 DIAMETER SIGNALING IN ROAMING ........................................................................36

    5.5.5.3 ACCESS POINT NAME RESOLUTION FOR HOME ROUTED PDN CONNECTIONS ...38

    6. STAGE 3 ASPECTS ....................................................................................................................40

    6.1 GENERAL .............................................................................................................................40

    6.2 STAGE 3 ASPECTS OF NHN ACCESS MODE ....................................................................40

    6.2.1 GENERAL .........................................................................................................................40

    6.2.2 RRC ..................................................................................................................................40

    6.2.3 STA INTERFACE ...............................................................................................................41

    6.2.4 EXTENDED AUTHENTICATION FOR NHN ACCESS MODE .............................................42

    6.3 STAGE 3 ASPECTS OF 3GPP ACCESS MODE (EPS-AKA) ................................................42

    6.4 STAGE 3 ASPECTS FOR 3GPP-BASED ACCESS MODE (NON-EPS-AKA) ........................42

    6.4.1 EXTENDED AUTHENTICATION FOR 3GPP-BASED ACCESS MODE (NON-EPS-AKA)...42

    6.4.1.1 SECURITY FUNCTION ..................................................................................................42

    6.4.1.2 AUTHENTICATION AND KEY AGREEMENT .................................................................42

    6.4.1.3 EPS KEY HIERARCHY ...................................................................................................43

    6.4.1.4 HANDLING OF EPS SECURITY CONTEXTS .................................................................43

    6.4.1.5 E-UTRAN KEY SETTING DURING AUTHENTICATION .................................................44

    6.4.2 EAP AUTHENTICATION ...................................................................................................44

    6.4.3 DOWNLINK EAP AUTHENTICATION NAS TRANSPORT ................................................44

    6.4.4 UPLINK EAP AUTHENTICATION NAS TRANSPORT ........................................................44

    6.4.5 CB1A INTERFACE ............................................................................................................44

    7. OTHER ASPECTS .......................................................................................................................45

    7.1 CBRSA NHN KPIS ................................................................................................................45

    APPENDICES (Informative) .............................................................................................................46

    APPENDIX A: OPERATIONAL CONSIDERATIONS .....................................................................46

    A.1: PRIVATE NETWORK DEPLOYMENT ....................................................................................46

    A.2: DEPLOYMENTS OF FIXED WIRELESS NETWORKS – GUIDELINES ....................................47

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    6

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    A.2.1: FIXED WIRELESS NETWORK DEPLOYED BY A SERVICE PROVIDER USE CASE ............47

    A.2.1.1: DEPLOYMENT OPTION 1 – WITH TUNNEL ................................................................47

    A.2.1.2: DEPLOYMENT OPTION 2 – WITHOUT TUNNEL ........................................................48

    A.2.2: FIXED WIRELESS NETWORK DEPLOYED BY NHN OPERATOR USE CASE ....................50

    CHANGE HISTORY ..........................................................................................................................52

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    7

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    LIST OF FIGURES

    Figure 5.2.1-1: Network Architecture – Use of CBRS band Without the CBRS-I ......................................... 16

    Figure 5.2.2.1-1: Network Architecture – CBRS Private Network using a CBRS-I and CBRS-NID ................ 17

    Figure 5.2.3-1: Network Architecture – Neutral Host Network and Participating Service Provider .......... 19

    Figure 5.2.4-1:Network Architecture – Private Network using Neutral Host Network .............................. 20

    Figure 5.2.5-1: Network Architecture – Hybrid Network ........................................................................... 21

    Figure 5.2.6-1: Network Architecture – Traffic Local Breakout in the SGW-LBO mode (left diagram), and

    S/PGW mode (right diagram) ...................................................................................................................... 23

    Figure 5.3.5-1: ECGI ..................................................................................................................................... 25

    Figure 5.3.6-1: GUMMEI ............................................................................................................................. 26

    Figure 5.3.7-1: TAI/TAC ............................................................................................................................... 27

    Figure 5.5.4.1-1: Network Architecture for 3GPP-based Access Mode (non-EPS-AKA) – Single

    Subscription ................................................................................................................................................ 33

    Figure 5.5.5.2-1 Illustration of the action of a Diameter Agent for routing IMSI requests from external

    networks ..................................................................................................................................................... 38

    Figure A.2.1.1-1-1: Fixed Wireless Deployment by SP – With Tunnel ........................................................ 47

    Figure A.2.1.1-1-2: Fixed Wireless Deployment by SP – With Tunnel (Call Flow) ...................................... 48

    Figure A.2.2-2-1: Fixed Wireless Deployment by NHN Operator ............................................................... 50

    Figure A.2.2-2-2: Fixed Wireless Deployment by NHN Operator (Call Flow) .............................................. 51

    LIST OF TABLES

    Table 6-1: Interpretation of “bssid-r12” Values.......................................................................................... 41

    Table 6-2: Feature Bits in “ssid-r12” ........................................................................................................... 41

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    8

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    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.

    [9] MFA TS 36.413, MulteFire Alliance (MFA), Architecture for Neutral Host Network Access Mode Stage 2, https://www.multefire.org/, Release 1.0.

    mailto:[email protected]://www.3gpp.org/https://www.multefire.org/http://www.3gpp.org/http://www.3gpp.org/http://www.3gpp.org/http://www.3gpp.org/http://www.3gpp.org/https://www.multefire.org/

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    9

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    [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.

    [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.

    mailto:[email protected]://www.multefire.org/http://www.3gpp.org/http://www.3gpp.org/https://www.multefire.org/http://www.3gpp.org/http://www.3gpp.org/http://www.3gpp.org/

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    10

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    [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.

    [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.

    mailto:[email protected]://standards.ieee.org/develop/regauth/tut/eui.pdfhttp://www.atis.org/01_committ_forums/ioc/Docs/IMSI-CBRS-Guidelines.pdfhttp://www.atis.org/01_committ_forums/ioc/Docs/IMSI-CBRS-Guidelines.pdfhttp://www.atis.org/01_committ_forums/ioc/Docs/IMSI-CBRS-Guidelines-AnnexA.pdfhttp://www.atis.org/01_committ_forums/ioc/Docs/IMSI-CBRS-Guidelines-AnnexA.pdfhttp://www.ietf.org/rfc/rfc3588.txt

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    11

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    [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.

    [42] GSMA IR.88 V16.0, 05 July 2017, LTE and EPC Roaming Guidelines

    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

    • 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

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    12

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    • 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

    • 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

    • SGW-LBO : SGW Local Breakout

    • 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

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    13

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    3.2 DEFINITIONS

    3GPP Access Mode : Operational mode between the UE and the network whereby communication is based on the 3GPP EPS architecture, functions and procedures as described in section 5.5.3 of [10].

    3GPP Access Mode (EPS-AKA)

    : An operational mode supported by a UE supporting the functions and procedures specified by 3GPP using E-UTRAN EPS-AKA authentication as defined in 3GPP TS 33.401 [11]. That is, 3GPP Access Mode (EPS-AKA) is the normal UE operation per 3GPP E-UTRAN specifications, including the use of EPS-AKA for authentication.

    3GPP-based Access Mode (non-EPS-AKA)

    : An operational mode 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 E-UTRAN specifications, except that a non-EPS-AKA method is used for authentication which includes EAP-TLS, EAP-TTLS. This allows the authentication of the UE without a USIM.

    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 [10].

    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’ (MME’)

    : The MME’ is a 3GPP LTE MME that is extended to support an interface to a AAA for EAP authentication methods.

    NHN (Neutral Host Network)

    : A Neutral Host Network is a network deployed and operated by an NHN operator, who may also be an independent entity, a MNO, or MSO, where the network resources are being shared by multiple services providers.

    NHN Access Mode : Operational mode between the UE and the network whereby communication is based on the NHN functions and procedures adapted

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    14

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    from the MulteFire Alliance (MFA) Release 1.0 specifications for neutral host deployment as described in section 5.5.2 of [10]. NHN referred in this definition is CBRSA NHN.

    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.

    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 : 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.

    SHNI Network : A network based on CBRS Alliance specifications that uses a SHNI 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

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    15

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    - 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:

    - 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.

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    16

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    ▪ 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.

    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

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    17

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    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-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).

    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-1: Network Architecture – CBRS Private Network using a CBRS-I and CBRS-NID

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    18

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    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-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-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.

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    19

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    Figure 5.2.3-1: Network Architecture – Neutral Host Network and Participating Service Provider

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    20

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    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.

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    21

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    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-

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    22

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    MME in a

    dual-mode EPC determines if the UE is accessing the network using NHN Access Mode upon 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.2.6 NETWORK ARCHITECTURE – TRAFFIC LOCAL BREAKOUT

    When a CBRS Network supports the Traffic Local Breakout feature, all or some of the UE traffic associated

    to a single PDN connection or multiple PDN connections can be offloaded to networks and/or applications

    in proximity to the RAN elements. Traffic filtering and offload is performed by the Local Gateway function,

    which can be implemented as one or a combination of packet GWs as follows:

    - SGW-LBO mode enables partial offload of the data traffic associated to the same APN, as well as the UE traffic associated to a single PDN connection. In this mode the Local Gateway function is

    a 3GPP-compliant SGW equipped with an SGi interface and capable of routing traffic to and

    from such interface.

    - S/PGW enables traffic offload for a whole APN, that is, for all traffic flows associated to such APN. The APN is terminated by a combined S/PGW function.

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    23

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    The architecture for traffic local breakout is shown in Figure 5.2.6-1, wherein the Local Gateway embodies

    one of the two modes above. The Traffic Local Breakout feature is available to UEs accessing the network

    using any of the access modes allowed by the CBRSA specifications.

    Figure 5.2.6-1: Network Architecture – Traffic Local Breakout in the SGW-LBO mode (left diagram), and S/PGW mode (right diagram)

    5.2.6.1 VOID

    5.3 VOIDIDENTITIES

    5.3.1 CBRS-I

    CBRS-I is a PLMN-ID and the value is a SHNI1 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

    EPC, using 3GPP EPC architecture

    SGW-LBO

    SGi

    S5/S11

    Local Services

    Internet

    LTE Radio

    CBRS RAN

    eNodeBeNodeB

    UE

    SGi

    MME, HSS

    S/PGW

    S11

    Local Services

    LTE Radio

    CBRS RAN

    eNodeBeNodeB

    UE

    SGi

    Network edge

    Network core

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    24

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    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 SHNI 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.

    - 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. An SHNI shall not be used as PSP-ID.

    1 The IMSI Administrator manages the IMSI resource using guidelines [28] and forms [29] developed by ATIS

    IOC.

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    25

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    - 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.

    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

    2 In these figures, ‘d’ is used to signify a decimal digit and ‘b’ a binary digit.

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    26

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    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 SHNI, 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 SHNI, 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 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.

    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.

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    27

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    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.

    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.

    4 CBRS UE profiles are implementation options for UE manufacturers and are not signaled to the network.

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    28

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    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 EPS Mobility Management (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).

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    29

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    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) o 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)

    - Not camped on CBRSA NHN Network, camped on SP Network (RRC Idle)

    - Not camped on CBRSA NHN Network, connected on SP Network (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) o All PDN services obtained from SP network

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    30

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    - camped on a CBRS access network [SP/NHN/Private] (RRC Idle)

    - connected on a CBRS access network [SP/NHN/Private] (RRC Connected) o SWu established with SP network to obtain certain services that are provisioned to use SP

    network

    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-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-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 FUNCTIONS AND PROCEDURES IN NHN ACCESS MODE

    5.5.2.1 GENERAL

    The following terminology differences exist between the terminology of the MulteFire Alliance and the

    terminology of the CBRS Alliance.

    - MFA TS MF.202 term “MulteFire cell” or “MF cell” is interpreted as “CBRS cell”

    - MFA TS MF.202 term “MulteFire RAN” is interpreted as “CBRS RAN”

    - MFA TS MF.202 term “MulteFire network” is interpreted as “CBRS network”

    - MFA TS MF.202 term “MulteFire AP” is interpreted as “CBRS eNB”

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    31

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    - MFA TS MF.202 term “MulteFire UE” is interpreted as “CBRS UE”

    - MFA TS MF.202 term “NHAMI” is interpreted as “CBRS-I”

    - 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:

    - Online Sign-up (OSU) and broadcast of indication for support of OSU,

    - Locally administered CBRS-NIDs,

    - CBRSA NHN service discovery,

    - Access service Authorization.

    5.5.2.2 MODIFICATIONS TO MULTIFIRE 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.

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    32

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    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.

    5.5.3 FUNCTIONS AND PROCEDURES IN 3GPP ACCESS MODE (EPS-AKA)

    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 #15 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 #15, 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.

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    33

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    5.5.4 FUNCTIONS AND PROCEDURES IN 3GPP-BASED ACCESS MODE (EPS-AKA)

    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.

    5.5.4.1 3GPP-BASED ACCESS MODE (NON-EPS-AKA) - SINGLE SUBSCRIPTION NETWORK ARCHITECTURE

    Figure 5.5.4.1-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-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.

    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’

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    34

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    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.5.4.2 3GPP-BASED ACCESS MODE (NON-EPS-AKA) - DUAL SUBSCRIPTION NETWORK ARCHITECTURE

    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 section 6.4.2 of 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 section 6.4.1 of 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

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    35

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    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.

    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

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    36

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    (non-EPS-AKA) Mode. No changes are required in applicable 3GPP specifications such as 3GPP TS 23.203

    [22], 3GPP TS 29.212 [23], or 3GPP TS 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.

    5.5.5 ROAMING SUPPORT

    Roaming across CBRS Networks may be achieved by mechanisms already specified in 3GPP and GSMA

    specifications – 3GPP TS 23.401[14] and IR.88[42].

    Support for roaming in networks using SHNI may also be accomplished through the use of a Diameter Edge

    Agent (DEA) to support messaging on the S6a (MME-HSS) interface between two Core networks. The

    mechanisms allow the DEA to route messages from visited networks to the appropriate home network

    identified by the IMSI Block Number (IBN).

    5.5.5.1 AUTHENTICATION OF AN SHNI SUBSCRIBER IN VISITED PLMN

    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 allow the UE to establish PDN services

    in the visited network. In order to accomplish this, the visited network should have a Diameter Edge Agent

    function with the ability to route all Diameter messages concerning the SHNI to the correct Home Network

    HSS, which is authoritative HSS for a subset of IMSIs belonging to the full Diameter realm corresponding to

    SHNI.

    5.5.5.2 DIAMETER SIGNALING IN ROAMING

    3GPP TS 23.401 [14] and TS 23.402 [4] define a direct Diameter signaling interface between the network

    elements of the visited network (Mobility Management Entity (MME), Visited Policy and Charging Rules

    Function (vPCRF)) and the network elements of the home Network (HSS and Home Policy and Charging Rules

    Function (hPCRF)). Diameter Base Protocol (IETF RFC 3588 [38]) defines the function of Diameter Agents to

    carry the signaling messages over such the interfaces between visited and home networks.

    The protocol defines the message format, which comprises a header and a set of data elements expressed

    as Attribute-Value Pairs (AVP), and 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.

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    37

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    All network elements in an EPC using a Diameter-based protocol for signaling exchange are assigned to at

    least one Diameter realm for Diameter routing. Diameter realms are defined in the form of FQDN for the

    purpose of addressing a network element supporting Diameter interfaces. Diameter realms can be optionally

    resolved by using DNS.

    A roaming device bearing IMSI from SHNI will trigger Diameter requests such as Update Location Request

    (ULR) from the MME on a visited network to the HSSs on exterior home networks. Unless the visited MME or

    its Diameter Agent is configured with exact host address of the destination HSS to which the Diameter

    signaling message shall be routed for the IMSI, the HSS at home network is addressed by Destination-Realm

    AVP dereived from IMSI containing a domain name constructed from the SHNI. A Diameter Agent (DA) may

    then use the Destination-Realm in conjunction with either the IMSI Block Number or the full IMSI information

    to route the message to correct destination network. The Destination-Realm constructured from the IMSI

    bearing the SHNI following the 3GPP TS23.003[16] cannot uniquely identify the correct HSS at home

    network.

    A DEA maintaining the mappings of known IBNs within the SHNI with the correct Diameter destination realms

    or hosts of the corresponding network element in the destination network, is a necessary function required

    to support roaming for SHNI networks.

    When a Diameter request arrives at a DEA with the standard realm based on SHNI, the DEA will further

    obtain the IBN or full IMSI information from the User-Name or User-Id AVP and optionally updates the

    Destination-Realm and Destination-Host AVPs with the correct mapping information and then route the

    message to the correct destination network element in an SHNI network. Where and how such DEA function

    is introduced to support roaming of SHNI is out of scope of this document.

    The IBN used in DEA Diameter routing should follow the IMSI Block Number assignments for Citizens

    Broadband Radio Service (CBRS) as defined in [29].

    mailto:[email protected]

  • CBRS Alliance CBRSA-TS-1002 V3.0.0

    38

    Copyright © 2020 CBRS Alliance • 3855 SW 153rd Drive • Beaverton, OR 97003 • www.cbrsalliance.org • [email protected]

    Figure 5.5.5.2-1

    Illustration of the action of a Diameter Agent for routing IMSI requests from external networks

    5.5.5.3 ACCESS POINT NAME RESOLUTION FOR HOME ROUTED PDN CONNECTIONS

    In case of roaming, the home PDN GW (PGW) selection is done based on the Access Point Name FQDN

    (APN-FQDN) resolution process by DNS. The APN-FQDN is derived from an APN that consists of an APN

    Network Identifier (APN NI) and an APN Operator Identifier (APN OI). The problem of the APN resolution

    in the case of SHNI is that the APN OI will be the same for many different networks using the SHNI, so the

    default APN-FQDN construction will not be able to provide uniquely identifiable home PGW.

    EXAMPLE1: For an APN of internet.mnc015.mcc234.gprs, the derived APN FQDN is

    internet.apn.epc.mnc015.mcc234.3gppnetwork.org

    If an APN is constructed using the APN-OI Replacement field (as defined in 3GPP TS 23.060 [3] and 3GPP

    TS 23.401 [14]), the APN-FQDN shall be obtained from the APN by inserting the labels "apn.epc." between

    the label "mnc" and its preceding label, and by replacing the label ".gprs" at the end of the APN

    OI Replacement field with the labels ".3gppnetwork.org".

    EXAMPLE 2: If an APN-OI Replacement field is province1.mnc015.mcc234.gprs and an APN-NI is internet,

    the derived APN FQDN is internet. province1.apn.epc.mnc015.mcc234.3gppnetwork.org

    When the visited network needs to resolve the Access Point Name (APN) name for a home routed PDN

    connection, the APN-FQDN for the home P-GW will need to include an additional unique identity as a sub-

    domain of the APN-FQDN in order to resolve the ambiguity problem of multiple network