cbrs network services use cases and requirements v3.0.0 18 ... · requirements may include network...

CBRS Network Services Use Cases and Requirements

CBRSA-TS-1001

V3.0.0

18 Feb 2020

CBRS Alliance CBRSA-TS-1001 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,

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

mailto:[email protected]

https://www.cbrsalliance.org/wp-content/uploads/2018/06/CBRS-Alliance_IPR-Policy_2016-06-301.pdf


2


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.



3


Table of Contents

1. Introduction and Scope ................................................................................................................7

1.1 Key Words ............................................................................................................................7

2. References ...................................................................................................................................7

3. Abbreviations and Definitions ......................................................................................................8

3.1 Abbreviations ........................................................................................................................8

3.2 Definitions ..............................................................................................................................9

4. CBRS Network Services Use Cases, Feature and Functionality Description ...............................12

4.1 Introduction ..........................................................................................................................12

4.2 Use Cases ............................................................................................................................15

4.2.1 SP Use Case .....................................................................................................................15

4.2.2 CBRSA NHN Use Case .....................................................................................................16

4.2.3 Private Network ...............................................................................................................17

4.2.3.1 Single Subscription UE Use Case ..................................................................................17

4.2.3.2 Multi-subscription UE Use Case .....................................................................................18

4.2.4 Hybrid Network Use Case ...............................................................................................19

4.2.5 Fixed Wireless Network Use Case ...................................................................................20

4.2.6 5G NR EN-DC Use Case ....................................................................................................2

4.3 Features/Functionalities .........................................................................................................4

4.3.1 CBRS UE Profile ..................................................................................................................4

4.3.2 Traffic LBO (Traffic Local Break Out) ................................................................................6

4.3.2.1 Traffic LBO - Use Case Mapping ...................................................................................7

4.3.3 Roaming Support ...............................................................................................................7

4.3.3.1 Roaming Support For Data Only Services ......................................................................8

4.3.3.2 Roaming Support For IMS-Based Services ......................................................................8

4.3.3.3 Roaming Support – Use Case Mapping .........................................................................8

5. Network Service Requirements ....................................................................................................9



4


5.1 Use Case Requirements ..........................................................................................................9

5.1.1 CBRSA NHN Use Case .......................................................................................................9

5.1.1.1 CBRSA NHN RAN Share Requirements ...........................................................................9

5.1.1.2 CBRSA NHN RAN Discovery Requirements ...................................................................10

5.1.1.3 CBRSA NHN Authentication Requirements ....................................................................10

5.1.1.4 CBRSA NHN Mobility Requirements .............................................................................10

5.1.1.5 CBRSA NHN General Security Requirements ...............................................................11

5.1.1.6 CBRSA NHN Measurement Requirements .....................................................................11

5.1.2 MSO Use Case .................................................................................................................12

5.1.2.1 MSO Specific RAN Requirements .................................................................................12

5.1.3 Fixed Wireless Network Use Case ...................................................................................12

5.1.3.1 CBRSA Fixed Wireless Network Access Architecture Requirements ..............................12

5.1.3.2 CBRSA Fixed Wireless Network Access Service Requirements .....................................12

5.2 CBRS Network Feature/Functionalities Requirements ..........................................................13

5.2.1 3GPP-based Access Mode (Non-EPS-AKA) .....................................................................13

5.2.1.1 General Requirements ..................................................................................................13

5.2.1.2 Authentication Requirements .........................................................................................13

5.2.2 UE Requirements ...............................................................................................................14

5.2.3 Traffic LBO Requirements .................................................................................................16

5.2.3.1 Traffic LBO Architecture Requirements .........................................................................16

5.2.4 Roaming Requirements for CBRS Networks ......................................................................16

5.2.4.1 Roaming Requirements for Data Only Services ............................................................16

5.2.4.2 Roaming Requirements for IMS-Based Services ............................................................17

APPENDICES (Informative) .............................................................................................................18

Appendix A: CBRS-Profile V Based UE Behavior .......................................................................18

Appendix B: SHNI and IMSI Block .............................................................................................21

Appendix C: REQUIREMENTS MAPPING - OLD vs NEW ...........................................................23



5


C.1 Requirement Numbering Format...............................................................................................23

C.2 Requirement Mapping ..............................................................................................................23

TABLE D-1: CHANGE HISTORY ........................................................................................................26



6


LIST OF FIGURES

Figure 4.1-1: Relationship among Roles ..................................................................................................... 14

Figure 4.2.1-1: SP Use Case Example .......................................................................................................... 16

Figure 4.2.2-1: NHN Use Case Example ...................................................................................................... 17

Figure 4.2.3.1-1: Single Subscription UE Use Case Example ....................................................................... 18

Figure 4.2.3.2-1: Multi-subscription UE Use Case Example ........................................................................ 19

Figure 4.2.4-1: Hybrid Network Use Case Example .................................................................................... 20

Figure 4.2.5-1: Fixed Wireless Network deployed by SP use case ................................................................ 1

Figure 4.2.5-2: Private CBRS Network providing Fixed Wireless and mobile services. Enterprise UE with

MNO subscription serviced through untrusted interface ............................................................................. 2

Figure 4.2.6-1: 5G NR NSA Network Architecture ........................................................................................ 3

Figure 4.2.6-2: 5G NR NSA EN-DC Network Architecture with U-Plane connection from EPC to eNB and

gNB ................................................................................................................................................................ 4

Figure A-1: Multi-subscription CBRS-Profile V Based UE example (Dual USIM Case) ................................ 18

Figure A-2: Multi-subscription CBRS-Profile V based UE example (USIM and non-USIM Subscription Case)

.................................................................................................................................................................... 19

Figure B-1: The SHNI used in CBRS creates a need to route IMSIs to networks; ........................................ 21

Figure B-2: A flow diagram detailing the IMSI Administrator’s role in assigning IBNs for use by CBRS

operators who do not possess their own HNI ............................................................................................ 22

LIST OF TABLES

Table 4.3.1-1: CBRS UE Profile Relationship ................................................................................................. 6

Table C.2-1: Requirement Mapping ............................................................................................................ 23

TABLE D-1: CHANGE HISTORY ..................................................................................................................... 26



7


1. INTRODUCTION AND SCOPE

This document is a Technical Specification that provides requirements for the operation of LTE radio networks in the CBRS band. The requirements shall be the input for the Stage 2 and 3 specification work. Different use cases for providing network services in the CBRS band are also described.

1.1 KEY WORDS

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 [8]. In addition, the key word “conditional” shall be interpreted to mean that the definition is an absolute requirement of this specification only if the stated condition is met.

The terminology “it shall be possible” means that the applicable feature or function shall be supported in the stage 2 and stage 3 specifications, but implementation is not mandatory by a vendor.

2. REFERENCES [1] Report and Order and Second Further Notice of Proposed Rulemaking, Amendment of the Commission’s

Rules with Regard to Commercial Operations in the 3550-3650 MHz Band, GN Docket No. 12-354, Federal Communications Commission, 21 April 2015.

[2] Order on Reconsideration and Second Report and Order, Amendment of the Commission’s Rules with Regard to Commercial Operations in the 3550-3650 MHz Band, GN Docket No. 12-354, Federal Communications Commission, 2 May 2016.

[3] WINN Forum, WINNF-TS-0016 v1.2.1, “SAS to CBSD Specification”, Jan 2018, https://workspace.winnforum.org/higherlogic/ws/public/document?document_id=4441

[4] 3GPP TS 32.450: Key Performance Indicators (KPI) for Evolved Universal Terrestrial Radio Access Network (E-UTRAN): Definitions.

[5] 3GPP TS 32.425: Performance Management (PM); Performance measurements - Evolved Universal Terrestrial Radio Access Network (E-UTRAN).

[6] 3GPP TS 32.455: Key Performance Indicators (KPI) for the Evolved Packet Core (EPC); Definitions.

[7] 3GPP TS 32.426: Performance Management (PM); Performance measurements - Evolved Packet Core (EPC) network.

[8] RFC-2119, “Key words for use in RFCs to Indicate Requirement Levels”, March 1997.

[9] 3GPP TS 23.401: “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access”.

[10] CBRSA-TS-1002-V3.0.0, “CBRS Network Service Stage 2 and 3 Specifications”, Note: Document not yet published, but should be published shortly and should be at the following link.

[11] 3GPP TS 33.401: “3GPP System Architecture Evolution (SAE); Security Architecture”.


https://tools.ietf.org/html/rfc2119

https://workspace.winnforum.org/higherlogic/ws/public/document?document_id=4441

https://www.cbrsalliance.org/specifications/


8


[12] CBRSA-TS-1003-V3.0.0, “CBRSA – Extended Subscriber Authentication Technical Specifications”,

Note: Document not yet published, but should be published shortly and should be at the following

link.

[13] 3GPP TS 23.402: “Architecture enhancements for non-3GPP accesses”

[14] 3GPP TS 31.102: “Characteristics of the Universal Subscriber Identity Module (USIM) application”

[15] International Mobile Subscriber Identity (IMSI) Assignment and Management Guidelines for

Shared HNI for CBRS Range Version 1.0 May 2018. Document can be found at the following link.

[16] CBRSA-TR-0100-V1.0.0, “CBRS Alliance Identifier Guidelines for Shared HNI”, Document can be

found at the following link.

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

[18] 3GPP TS 23.228: “IP Multimedia Subsystem (IMS); Stage 2”.

[19] 3GPP TS 37.340: “3rd Generation Partnership Project, Technical Specification Group Radio

Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA) and NR; Multi-connectivity;

Stage 2”.

3. ABBREVIATIONS AND DEFINITIONS

3.1 ABBREVIATIONS

• 3GPP : Third Generation Partnership Project

• AAA : Authentication, Authorization and Accounting

• AKA : Authentication and Key Agreement

• APN : Access Point Name

• CBRS : Citizens Broadband Radio Service

• CBRSA : CBRS Alliance

• DSC : DIAMETER Signalling Controller

• DHCP : Dynamic Host Configuration Protocol

• DSCP : Differentiated Services Code Point

• EMM : EPS Mobility Management

• EPC : Evolved Packet Core

• EPS : Evolved Packet System

• ePDG : Evolved Packet Data Gateway

• ESM : EPS Session Management

• FCC : Federal Communications Commission

• GAA : General Authorized Access

• GUTI : Globally Unique Temporary Identifier

• HNI : Home Network Identity

• IBN : IMSI Block Number

• IoT : Internet of Things



https://www.atis.org/01_committ_forums/ioc/docs/IMSI-CBRS-Guidelines_v1.1.pdf



9


• IIoT : Industrial Internet of Things

• IMS : IP Multimedia Subsystem

• IMSI : International Mobile Subscriber Identity

• ISP : Internet Service Provider

• KPI : Key Performance Indicator

• LBO : Local Break Out

• LTE : Long-Term Evolution

• MNO : Mobile Network Operator

• MSO : Multiple-System Operator

• MVNO : Mobile Virtual Network Operator

• NH : Neutral Host

• NHN : Neutral Host Network

• NW : Network

• OTA : Over The Air

• OTT : Over The Top

• PDN : Packet Data Network

• PLMN : Public Land Mobile Network

• PSP : Participating Service Provider

• QOS : Quality Of Service

• R&O : Rule and Order

• SCG : Secondary Cell Group

• SHNI : Shared HNI

• SLA : Service Level Agreement

• SP : Service Provider

• SIB : System Information Block

• TAU : Tracking Area Update

• UE : User Equipment

• USIM : Universal Subscriber Identity Module

• VLAN : Virtual Local Area Network

• VoLTE : Voice over LTE

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



10


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 Network : One or more CBSDs, along with their related network elements, operated in compliance with 47 CFR Part 96, all other relevant FCC regulations, and all relevant technical and operational recommendations of the CBRS Alliance.

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

EPS-AKA : 3GPP LTE Authentication and Key Agreement (AKA) defined in 3GPP [11]. In this method, mutual authentication is achieved between a user and a network by a challenge and response protocol based on a shared cryptographic key K, which is only available to USIM an user’s home EPC network. In addition to authentication, it also defines a process of establishing encryption and integrity keying materials to be used by the user equipment (UE) and the network to protect subsequent communication.

ISP (Internet Service Provider)

: An entity which offers Internet Access and (possibly) other related services.

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.

Mobile Network Operator (MNO)

: A Mobile Network Operator, also known as a wireless service provider, wireless carrier, cellular company, or mobile network carrier, is a provider of wireless communications services that owns or controls all the elements necessary to sell and deliver services to an end user including radio spectrum allocation, wireless network infrastructure, backhaul infrastructure, billing, customer care, provisioning computer systems and marketing and repair organizations.

MSO (Multiple System Operator)

: A company which owns multiple fixed access systems and offer services such as (but not limited to) Internet Access, Video, Voice, etc. to residences and enterprises. A MSO may also own or control the elements necessary to deliver wireless services, in which case it would also be considered a MNO.



11


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

NHN Core Network : The Core Network part of a NHN.

NHN RAN : The RAN part of a NHN deployed in the CBRS band.

Non-EPS-AKA : Non-EPS-AKA refers to extended authentication methods as defined in TS-1003. Further, Non-EPS-AKA also refers to an authentication method that does not mandate the use of USIM for protecting authentication credentials.

Non-USIM Authentication : Non-USIM Authentication refers to any authentication method that does not mandate the use of USIM for protecting authentication credentials. Extended authentication methods defined in CBRSA TS-1003 do not mandate the use of USIM. Thus, Non-USIM is often used to refer to CBRSA authentication methods, and it is also used interchangeably with Non-EPS-AKA. Depending on the context, the terminology of Non-SIM, non-USIM, Non-USIM authentication, Non-EPS-AKA authentication, Non-USIM credentials, or Non-USIM subscription may also be used. Note that CBRSA does not mandate the use of USIM or prevent USIM from being used for credential storage.

OTA : Over The Air is a mechanism to communicate with wireless device to provision, update and manage.

OTT Video : Streaming video distribution to consumers over the internet.

Participating Service Provider (PSP)

: A PSP is a Service Provider (SP) offering services to its subscribers via a 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.

PSP Core Network (PSP CN)

: A core network operated by a PSP.

PSP RAN : A 3GPP RAN network operated by a PSP. Only a PSP which is an MNO is expected to have a RAN.



12


Service Provider (SP) : An entity such as an MNO, MVNO, MSO, or ISP that provides services to its Subscribers and can authenticate and authorize its Subscribers. Any entity that has a service agreement with Subscribers can act as a SP.

SWu : The interface from a UE through an untrusted IP access to an operators ePDG (Evolved Packed Data Gateway). The SWu interface allows for establishing or disconnecting a tunnel between the UE and ePDG.

USIM : Universal SIM is defined in 3GPP [14] as a software application resided in UICC that can store sensitive data including, but not limited to, shared secrets, IMSI, and keying materials used by 3GPP authentication and key agreement.

USIM Authentication : USIM Authentication refers to any authentication method that mandates the use of USIM for protecting authentication credentials. Since EPS-AKA is the only authentication method in 3GPP LTE which also mandates the use of USIM, USIM authentication is often used interchangeably with EPS-AKA in CBRSA specifications.

4. CBRS NETWORK SERVICES USE CASES, FEATURE AND FUNCTIONALITY

DESCRIPTION

4.1 INTRODUCTION

This section describes the different use cases that can be enabled via the CBRS band and features/functionalities that can be supported across multiple use cases. The use cases define the roles involved in providing service and describe how specific entities fulfill the roles in each use case. It is important to recognize the difference between role and entity, and to recognize that a single entity may fulfill more than one role in a given use case.

The following text from the FCC Report & Order [ref. 1, Pg. 107, Para. 8] outlines some use cases anticipated for the CBRS band by [1].

As a result of the Commission’s actions in the R&O and Second Order and Order on Reconsideration, small business will have access to spectrum that is currently unavailable to them. The potential uses for this spectrum are vast. For example, wireless carriers can deploy small cells on a GAA basis where they need additional capacity. Real estate owners can deploy neutral host systems in high-traffic venues, allowing for cost-effective network sharing among multiple wireless providers and their customers. Manufacturers, utilities, and other large economic sectors can construct private wireless broadband networks to automate industrial processes that require some measure of interference protection and yet are not appropriately outsourced to a commercial cellular network. All of these applications can potentially share common wireless technologies, providing economies of scale and facilitating intensive use of the spectrum.



13


There are three roles involved in CBRS service use cases; Service Provider, CBRS Network Operator, and Subscriber.

A Service Provider (SP) authenticates and authorizes its subscribers and provides services to them. Any entity that has a service agreement with Subscribers can act as an SP. For example, entities like traditional communications providers including MNOs, MSOs, MVNOs and ISPs are SPs that provide services to their customers. An entity like an enterprise plays a SP role in providing services to its employees, customers, or other related parties. A Service Provider must have the technical ability to provide suitable Authentication and Authorization of its Subscribers; it may or may not have other components of a traditional EPC. Services offered by SPs include, e.g., VoLTE, Internet access, IoT, etc. A Participating Service Provider (PSP) is an SP having a business agreement with NHN Operator to offer services via the specific Neutral Host.

A CBRS Network Operator deploys a CBRS network with an intention to provide connectivity and/or enable services to Subscribers of Participating Service Provider(s). A CBRS network may be deployed in a variety of locations, including public venues (malls, airports, city squares) and enterprises (offices, hotels, etc.). Any entity that deploys a CBRS Network plays a role of a CBRS Network Operator. For example, when an SP deploys its own CBRS network, the SP also plays a role of CBRS Network Operator.

A Subscriber is authenticated and authorized by one or more Service Providers it has service agreement with, and upon successful authentication and authorization, is provided with services from SPs. For clarity, the term “Subscriber” may refer to a person or a device; it is the device that is subject to authentication and authorization.

Figure 4.1-1 describes the relationships among three different roles.



14


Service Provider 1

CBRS Network Operator

Subscriber of SP1 Subscriber of SPn

Service Provider n

1. Subscriber-SP Relationship(Service Agreement)

2. CBRS Network Operator – SP Relationship:

Business Agreement

Service Provider 2

Subscriber of SP2

Figure 4.1-1: Relationship among Roles

1. Subscriber – Service provider relationship: A Subscriber has a service agreement with a Service Provider

for the services offered by that Service Provider. The Service Provider has all the information about the

Subscriber enabling it to provide authentication of the Subscriber, authorization of the services for the

Subscriber, and Subscriber management. The service agreement could be, for example, a traditional

monthly-billing arrangement, or may take other forms such as on-line sign-up, pre-installed certificates,

or vending-machine SIMs. A subscriber may have a service agreement with more than one Service

Provider.

2. Service Provider – CBRS Network Operator relationship: a CBRS Network Operator has a business

agreement with one or more Service Providers to provide connectivity and/or enable services on one or

more of its CBRS Networks to the Service Providers’ Subscribers. The business agreement includes all the

aspects for SPs to be able to provide services to their Subscribers on CBRS networks. This business

agreement can include, for example, technical arrangements enabling the Service Provider to provide

at least authentication and authorization of its Subscribers when they use the CBRS Network.

Note : This relationship diagram only covers the relationship between CBRS roles. The existing business relationship among Service Providers, including traditional roaming agreement, continues to be in place independent of the relationship among CBRS roles. For example, Subscribers of SPs may be able to roam onto the CBRS Network deployed by



15


other SPs using conventional 3GPP roaming procedures if there is a roaming agreement between those SPs.

Depending on the roles the entities play, different use cases arise. Each use case is described in more detail in subsequent sections.

4.2 USE CASES

4.2.1 SP USE CASE

For the SP use case, an SP deploys the CBRS network itself and, hence, plays the role of a CBRS Network Operator as well as a SP. Subscribers of the SP benefit from improved user experience and/or an extended coverage through CBRS network.

Figure 4.2.1-1 shows an example of SP use case. In this example, SPs could represent traditional MNOs and MSOs, and other traditional types of SPs. MNO1 deploys a CBRS Network itself; hence plays the role of both SP and CBRS Network Operator. Subscribers of MNO1 have access to the CBRS Network deployed by MNO1. Other SPs (MSO1 and MNO2 in this example) have no relationship with the CBRS Network deployed by MNO1; hence the Subscribers of MSO1 or MNO2 do not have access to this CBRS Network.

For the SP use-case when the SP is a MNO, the 3GPP defined architectures in [9] using S1 can be used. In this case, if other SPs have traditional roaming agreements with MNO1, then Subscribers of those SPs may be able to roam onto the CBRS Network deployed by MNO1 using conventional 3GPP roaming procedures.



16


MNO 1

CBRS Network Deployed by MNO1

Subscriber of MNO1 :Access to CBRS NW deployed by MNO1

Subscriber of MNO2NO Access to this

particular CBRS NW

MNO 2

MNO1 plays a role of both SP and CBRS NW Operator

MSO 1

Subscriber of MSO1NO Access to this

particular CBRS NW

NO Relationship between MSO1/MNO2 and CBRS Network Operator (MNO1)

SP Use Case

Figure 4.2.1-1: SP Use Case Example

4.2.2 CBRSA NHN USE CASE

The NHN (Neutral Host Network) use case involves the deployment of a CBRS network by a NHN Operator with the intention of providing service to the Subscribers of one or more participating Service Providers through the CBRS Network while the Subscribers are on the CBRS Network. Subscribers have no direct association with the NHN Operator. All subscriber management functions (e.g., billing and payment, customer care, provision of SIMs or certificates) are performed by the SP. The NHN Operator has a business agreement with a SP to provide service to participating SP’s subscribers while they are on the CBRS Network. Note that there is no direct service or business relationship between Subscriber and CBRS Network Operator. A CBRS Network Operator simply provides connectivity and/or enables services to the Subscribers of participating SPs.

Figure 4.2.2-1 shows an example of NHN use case. In this example, SP entities MNO1 and MSO1 have business agreements with a NHN Operator which is a CBRS Network Operator. Through these business agreements, MNO1 and MSO1 become Participating Service Providers (PSPs) for this CBRS Network and the Subscribers of MNO1 and MSO1 have access to the CBRS Network deployed by the NHN Operator. MNO2 does not have a relationship with this NHN Operator; hence Subscribers of MNO2 do not have access to this CBRS Network deployed by the NHN Operator.



17


MNO 1

CBRS Network Deployed by NHN Operator

Subscriber of MNO1 :Access to CBRS NW deployed by NHN

Operator

Subscriber of MNO2:NO Access to this

particular CBRS NW deployed by NHN

Operator

MNO 2

Business agreement betweenNHN Operator and MNO1

MSO 1

Subscriber of MSO1:Access to CBRS NW deployed by NHN

Operator

NO Relationship between MNO2 and CBRS Network Operator

(NHN Operator)

NHN Use Case

Business agreement betweenNHN Operator and MSO1

Figure 4.2.2-1: NHN Use Case Example

In the above example, the business relationship between the NHN Operator and SP entities (MSO1 and MNO1) can also be based on 3GPP specification defined roaming relationship wherein the NHN becomes the Visited Network for subscribers belonging to SP entities (MNO1 and MSO1). CBRS Alliance does not exclude any such 3GPP based NHN architecture.

Any impacts to 3GPP defined architecture as a result of IMSI blocks allocated within the PLMN ID allocated for CBRS (CBRS SHNI [15]) shall be studied as part of Stage 2 work.

4.2.3 PRIVATE NETWORK

4.2.3.1 SINGLE SUBSCRIPTION UE USE CASE Private CBRS network is deployed to provide service to employees, machines and other devices as authorized by the Private Network provider. In this case, the private network operator plays the roles of both SP (providing services to the authorized users/devices) and CBRS Network Operator (deploying the CBRS network). A private network operator is one that deploys and manages an LTE Core network and an LTE RAN operating in the CBRS band and provides services exclusively for its own Subscribers. The end user devices in a private network shall have a business relationship with the private network operator.

Figure 4.2.3.1-1 shows an example of private network use case. In this example, Enterprise 1 deploys a CBRS Network; hence playing the role of both SP and CBRS Network Operator. Employees or customers of Enterprise 1 are granted a subscription to access the CBRS Network deployed by Enterprise 1. Enterprise 1



18


does not have any business relationship with MNO1 or MSO1; hence the Subscribers of MNO1 or MSO1 do not have access to the CBRS Network deployed by Enterprise 1.

MNO 1

CBRS Network Deployed by Enterprise 1

(Enterprise 1 plays a CBRS Network Operator role)

Subscriber of MNO1 :NO Access to this

particular CBRS NW deployed by Enterprise 1

Employee of Enterprise1:

Access to CBRS NW deployed by Enterprise 1

Enterprise 1(Enterprise1 plays an SP role)

MSO 1

Subscriber of MSO1:NO Access to this

particular CBRS NW deployed by Enterprise 1

NO Relationship between MNO1/MSO1 and CBRS Network

Operator (Enterprise1)

Private NW Use Case

Figure 4.2.3.1-1: Single Subscription UE Use Case Example

4.2.3.2 MULTI-SUBSCRIPTION UE USE CASE This is a variation of the Private Network use case where a UE used in a Private Network has, in addition to a subscription with the Private Network, a subscription with another SP. The SP subscription can be used to access the SP’s network when the Private Network coverage is unsatisfactory or when a Subscriber wants to access SP services. The device uses separate credentials for access to the Private Network and to the SP’s network. A Subscriber may use an SP subscription to access SP services using a Private Network as an untrusted network. In this case, the subscriber can use untrusted non-3GPP access procedures to access SP services. The tunnel is setup using IP connectivity provided by a Private Network after gaining the connectivity by authenticating with the Private Network using Private Network credentials.

Figure 4.2.3.2-1 shows an example of a Private Network use case with dual subscription. In this example, Enterprise 1 deploys a CBRS Network and provides private services to the authorized users. Enterprise 1 does not have any business relationship with MNO1. An employee of Enterprise 1 also has a subscription to MNO1 with a separate MNO1 credential. This employee can access the private network services through the CBRS network deployed by Enterprise 1. The employee can also access the MNO services with the CBRS network acting as an untrusted non-3GPP access (e.g., the UE can connect to the MNO’s ePDG to access MNO network/services).



19


Figure 4.2.3.2-1: Multi-subscription UE Use Case Example

4.2.4 HYBRID NETWORK USE CASE

The hybrid use case combines more than one use case described in above sections. Specifically, the hybrid use case combines the CBRSA NHN use case with the other use cases, i.e. SP use case or Private Network use case. In hybrid use case, an SP or Private network operator provides services to its own Subscribers while simultaneously provides access to the PSP’s subscribers. Figure 4.2.4-1 shows an example of a hybrid use case.

SP1 (MNO/MSO/Enterprise) deploys the CBRS network for its own Subscribers and other PSPs’ Subscribers. SP1 has a business relationship with MNO1 so that MNO1’s Subscriber can access the CBRS network. The Subscriber of SP1 accesses the CBRS network deployed by SP1 to access the SP1 services. The Subscriber of MNO1 accesses the CBRS network deployed by SP1 to access the MNO1 services.

MNO2 does not have a business relationship with SP1 for CBRS access, hence, the Subscriber of MNO2 does not have the access to CBRS network deployed by SP1.



20


MNO 1

CBRS Network Deployed by Service Provider 1 (MNO/MSO/Enterprise)

Subscirber of MNO1 :Access to CBRS NW deployed by Service

Provider 1

Subscriber of MNO2:NO Access to this

particular CBRS NW deployed by Service

Provider 1

MNO 2

Business agreement betweenService Provider and MNO1

Service Provider 1(MNO/MSO/Enterprise)

Subscriber of Service Provider 1:

Access to CBRS NW deployed by Service

Provider 1

NO Relationship between MNO2 and Service Provider 1

Hybrid Use Case

Figure 4.2.4-1: Hybrid Network Use Case Example

4.2.5 FIXED WIRELESS NETWORK USE CASE

In this use case the CBRS Network is deployed by a Fixed Wireless Service Provider to provide data communication services for residential and enterprise customers using Fixed Wireless Access equipment.



1


Figure 4.2.5-1: Fixed Wireless Network deployed by SP use case

Residential customers typically require Internet Access, VoIP and OTT video services.

Enterprise customers may require Internet access, corporate (private) data services, corporate VoIP and etc. private applications. Such customers may have one or more locations connected by wireless and/or wireline technologies with multiple computers in each location. In many cases, to serve corporate needs, Enterprise customers require transparent Layer 2 services between their locations from the Fixed Wireless Network Service Provider - plain Ethernet, 802.1q VLANs, etc. with corresponding QOS per service.



2


Figure 4.2.5-2: Private CBRS Network providing Fixed Wireless and mobile services. Enterprise UE with MNO subscription

serviced through untrusted interface

4.2.6 5G NR EN-DC USE CASE

Figure 4.2.6-1 depics the network archituctre used for 5G NR Non-Standalone (NSA) deployment. In 3GPP Release 15, the UEs can employ EUTRA-NR Dual Connectivity (EN-DC). 3GPP EN-DC can be used together with other network architectures and associated Use Cases defined in this document. The EN-DC Use Case supports higher bandwidths, low latency and increased reliability.

3GPP Release-15 specifications does not support, from an end-to-end standpoint, Closed Subscriber Group (CSG) in NR, neither does it support EN-DC with MeNB as a CSG cell.



3


en-gNB

eNB

S1

-U

S1

S1

X2

E-UTRAN

EPC

MME/S-GW

en-gNB

eNB

S1

-U

S1 S1

X2

MME/S-GW

X2

X2-U

S1-U S1-U

Figure 4.2.6-1: 5G NR NSA Network Architecture

NR Standalone (SA) for Private, and Neutral Host Networks will be supported in 3GPP Releases beyond Release-15. However, Private Network deployment with NR Non-Standalone EN-DC is supported with the use of Shared-HNI in CBRS Alliance Release 3 specifications. This document addresses the deployment of EN-DC architecture only. The support of Public, Private, and Neutral Host Networks with 5G NR SA architectures and other 5G NR NSA architectures are addressed in future CBRS Alliance releases.



4


Figure 4.2.6-2: 5G NR NSA EN-DC Network Architecture with U-Plane connection from EPC to eNB and gNB

E-UTRA-NR Dual Connectivity (EN-DC) handles authentication and authorization through the LTE EPC. The 5G NR EN-DC architecture might be deployed in different architecture, depending on whether there is a U-Plane connection from eNB to EPC, or from gNB to EPC. Figure 4.2.6-2 depicts one such architecture of 5G NR NSA EN-DC, wherein, the Secondary Cell Group (SCG) bearer has a U-Plane connection between 5G NR gNB and the core network, as well as another U-Plane connection between the LTE eNB and 5G NR gNB to enable SCG split bearer.

4.3 FEATURES/FUNCTIONALITIES

4.3.1 CBRS UE PROFILE

The section defines different capabilities of the UE into CBRS Profiles. A UE can support one or more of these profiles. A CBRS Profile II based UE is the minimum level required for CBRSA NHN support. No assumptions are made about support for other radio technologies such as 3G.



5


1. A CBRS-Profile I is support for 3GPP procedures with CBRS band.

• A CBRS-Profile I based UE does not have the capability to attach to a CBRSA NHN and does not have the capability to support CBRSA NHN procedures.

• A CBRS-Profile I based UE supports only 3GPP Access Mode (EPS-AKA) in CBRS band.

2. An extended CBRS-Profile I, also known as a CBRS-Profile I-A is the capability of attaching to 3GPP-based access mode (non-EPS-AKA)

• A CBRS-Profile I-A based UE does not have the capability to attach to a CBRSA NHN and does not have the capability to support CBRSA NHN procedures.

• A CBRS-Profile I-A based UE can either attach using 3GPP-based Access Mode (non-EPS-AKA) or using 3GPP Access Mode.

3. A CBRS-Profile II is the capability to support CBRSA NHN selection procedures, mobility procedures, security procedures, and RAN identifiers. A CBRS-Profile II based UE is capable of supporting a single LTE radio access network connection and dual EMM context. A CBRS-Profile II based device can be EMM Registered on at most one access network at a time.

• For a CBRS-Profile II based UE, all PDN connections are assigned to the same access network (e.g., all on an SP network or all on CBRSA NHN).

• A device based on CBRS-Profile II supports CBRS-Profile I and optionally supports CBRS-Profile I-A

4. A CBRS-Profile III based UE is capable of supporting a single LTE radio access network connection, dual EMM contexts, and can listen for paging on both EMM contexts, plus search and identify target cells on the non-serving CBRS Network or SP network (possibly at some cost to performance). A CBRS-Profile III based device can be EMM Registered on two access networks simultaneously.

• For a CBRS-Profile III based UE, PDN connections can be assigned to different access networks (e.g., Internet on the CBRSA NHN and VoLTE on the MNO network). Network-originated data for a PDN connection, if needed, triggers a paging procedure on the corresponding access network.

• Since a CBRS-Profile III based UE can connect to a single radio access network connection, it can send/receive data only on one access network at a time. In order for the network to maintain the correct EMM and ESM status of the UE, a CBRS-Profile III based UE may have to perform periodic TAU procedures on the access network where it is in IDLE state.

• A device based on CBRS-Profile III supports CBRS-Profile I and CBRS-Profile II. Such a device optionally supports CBRS-Profile I-A

5. A CBRS-Profile IV based UE is capable of supporting dual LTE radio access network connections simultaneously, dual EMM contexts, and dual ESM contexts.

• User-plane data can flow over both ESM contexts simultaneously, at the granularity of PDN connections.

• A device based on CBRS-Profile IV supports CBRS-Profile I and CBRS-Profile II. Such a device optionally supports CBRS-Profile I-A



6


6. A CBRS-Profile V based UE is capable of supporting a single LTE radio access network connection at a time, has multiple subscriptions and can have the ability to choose the subscription for specific services while using a different subscription for other services including voice. A CBRS-Profile-V based UE is capable of setting up an SWu tunnel via the EMM Registered Access Network to avail services using the other subscription. Reference Appendix A.

• A device based on CBRS-Profile V supports CBRS-Profile I. Such a device optionally supports CBRS-Profile I-A and CBRS-Profile II.

The following table shows another view of the UE profiles.

Table 4.3.1-1: CBRS UE Profile Relationship

4.3.2 TRAFFIC LBO (TRAFFIC LOCAL BREAK OUT)

Some service scenarios require the subscribers’ data traffic to stay local, that is, to be routed to networks and/or applications in proximity to the RAN elements. The reasons for local routing span from security and privacy constraints, performance improvement (e.g., latency), cost reduction, or other deployment preferences.

Exemplary use cases might be the following.

1. A large enterprise consists of several facilities distributed around geographically scattered sites.

Each site may have different service relations with the mobile network infrastructure providers

locally available, utilizing more than one of the service models among those described in the

following sections. For instance, the enterprise might deploy the Private Network model for the

primary site, which is in charge of subscriber authentication, UE IP address assignment and bearer

creation for the other connected sites as well. Still, the organization requires to collect part of the

user traffic generated from all the sites at the primary site and offload the remaining at each

corresponding site. Because users may move from one site to the other, a single default APN is

provisioned in all the subscribers’ devices, which resolves to a single Packet Data Gateway sitting

on the primary site.

2. An MNO services its users localized at a given defined venue, such as a stadium, a theme park, and

similar, using the local third party’s CBRS network infrastructure. In addition, the facility houses some

CBRS UE Profile Supported Profiles Optional Profile support

CBRS-Profile I None None

CBRS-Profile I-A CBRS-Profile I None

CBRS-Profile II CBRS-Profile I CBRS-Profile I-A

CBRS-Profile III CBRS-Profile I, CBRS-Profile II CBRS-Profile I-A

CBRS-Profile IV CBRS-Profile I, CBRS-Profile II CBRS-Profile I-A

CBRS-Profile V CBRS-Profile I CBRS-Profile I-A, CBRS-Profile II



7


sort of app-based service to customers for enhanced user experience, like real time video streaming,

AR/VR entertainment, video clips and others. Since the information is meant to be produced and

consumed on site, the MNO aims at routing the traffic associated to those applications locally,

avoiding hauling it to the centralized EPC.

3. An Industrial IoT (IIoT) deployment enables robots, machinery and other equipment within a factory

with LTE connectivity. The equipment might be connected to local servers for the closed control loop

as well as to remote servers for data storage and processing.

4. An SP may leverage the public cloud infrastructure to run the EPC control plane, whereas the data

plane is routed through on-premise infrastructure, ensuring traffic isolation so that users belonging

to different logical networks can have the traffic breakout to different and separated local network

segments.

Moreover, there is no 3GPP-defined mechanism for an LTE network to enable traffic offload of all or some UE traffic associated to a single PDN connection, as per the use cases listed above. Such enablers essentially embed part of or all the 3GPP EPC gateways’ functionalities (and this approach is defined in 5G specifications too) and can be used in a CBRS Network as well to enable the Traffic LBO feature described above. Such network element implementing the Traffic LBO enabler may be deployed as part of the CBRS Network and thus belonging to the CBRS Network Operator. In this case, the relation between the SP and the CBRS Network Operator should provide means to let the former control and authorize which traffic should be broken out by the latter.

4.3.2.1 TRAFFIC LBO - USE CASE MAPPING

The ability to route traffic to a local network may be a feature of a CBRS-based deployment based on any of the service relations described in section 4.2. However, in the general case, not all the user data traffic needs to be forwarded to a local network, and different filtering granularity may be necessary, often demanding to seamlessly offload part of traffic of the same UE. Thus, SP’s alone may authorize and select the traffic to be broken out, regardless if the local network and applications belong to the SP or not.

4.3.3 ROAMING SUPPORT

CBRS based networks can be deployed using the SHNI or any PLMN-ID. Various use cases for CBRS based networks as defined in Section 4.2. Of these use cases, when CBRS based Private and Hybrid networks are deployed using SHNI, the CBRS Service Provider may enter into business agreements with other SPs or CBRS Service Providers. Via such business agreements, the CBRS network operators can enable roaming of their own subscribers into other networks or can allow their own network to serve the subscribers of other networks (as Visited Network).

Two categories of services can be offered by the Visited Network for the in-bound roamers (or subscribers belonging to other operators) – Data only services and/or IMS-Based services. 3GPP TS 23.401 covers the aspects of Home Routing and LBO of PDN services in the Visited Network. All these aspects covered in the 3GPP specifications are based on the underlying premise that all networks are separated using unique PLMN ID. Since all SHNI based networks use the same PLMN ID (SHNI), prevalent procedures for resolving the Home Operator cannot be used to identify the Home CBRS Operator. The contents of this specification focus on the following aspects –



8


- Authentication procedure: The procedure by which the subscribers are authenticated and

authorized in a Visited Network. In order to complete the Authentication procedure, the Visited

Network have to use IBN to locate the Home Network. For example, Locating Home HSS can be

done using DSC (based on IBN in the IMSI)

- PDN Service resolution: This includes APN management and resolution since the combination of APN

and PLMNID may no longer be universally unique. For resolving APNs, IBN in the IMSI should be

considered.

Note : This specification does not consider subscribers belonging to non-SHNI based operator network roaming into SHNI based CBRS networks. Since non-SHNI based operators will have a unique PLMN ID, 3GPP TS 23.401[11] and GSMA IR.88[17] specification capture the details for such roaming support.

4.3.3.1 ROAMING SUPPORT FOR DATA ONLY SERVICES

Data only services involve all the services that do not require an IMS. However, data services may include OTT voice. Data services can be Home Routed or Local Breakout at the Visited Network and such policy decisions are beyond the scope of this specification.

4.3.3.2 ROAMING SUPPORT FOR IMS-BASED SERVICES

The support for IMS-based services, such as VoLTE, SMS over IMS, etc. might be available at CBRS Network operators that use the SHNI. Such services are available to subscribers when they roam out of their home CBRSA network, in which case the Visited Network may be provided by an MNO that does not use the SHNI or a CBRS Network Operator that uses the SHNI.

The use of the SHNI poses some limitations in the ability of legacy network operators to route IMS-based services for visiting subscribers. The CBRSA specifications define methods to support roaming for IMS-based services to subscribers that belong to a CBRS Network Operator that uses the SHNI. Furthermore, IMS-based services roaming is described in the scenario of a Visited Network that operates as a NHN.

4.3.3.3 ROAMING SUPPORT – USE CASE MAPPING

This feature is applicable for all roaming scenarios where either the EPC HPLMN or EPC VPLMN uses SHNI. For all those scenarios where EPC HPLMN and EPC VPLMN use uniquely identifiable PLMN ID, 3GPP TS 23.401[11] and GSMA IR.88[17] specification apply. In order to support roaming, a business agreement, also referred as roaming agreement, is essential between the Service Provider of the Home and the Visited PLMN. The roaming support for the use cases described in section 4.2 are as follows:

• CBRS Service Provider Operating a Private network can enter into such roaming agreements with other Service Providers. When such agreements are in place, the private network may serve as Home PLMN or Visited PLMN depending on the roaming scenario.

• A NHN operator does not offer service to subscribers in the NHN. A PSP offers service to subscribers in the NHN. The agreement between NHN Operator and PSP are not considered as roaming agreements. Any PSPs offering a service to subscribers via the CBRS NHN may enter into a roaming agreement with other Service Providers. In such scenario roaming is based on the PLMN ID operated by the PSP.



9


• In a scenario that a CBRS Service Provider also offer a Neutral Host service, i.e. the network is a Hybrid Network, the CBRS Service Provider and/or PSPs in such a network may enter into a roaming agreement with other Service Providers. In such scenario roaming is based on the PLMN ID operated by the PSP or the PLMN ID used by the CBRS Service Provider (depending on UE policies).

5. NETWORK SERVICE REQUIREMENTS

These requirements support the use cases defined in section 4.

5.1 USE CASE REQUIREMENTS

5.1.1 CBRSA NHN USE CASE

This section includes requirements for sharing LTE radio access and the CBRSA NHN Core network among multiple Participating Service Providers.

5.1.1.1 CBRSA NHN RAN SHARE REQUIREMENTS

R1-NHN-RSH-001 It shall be possible to organize a set of LTE CBSDs as a CBRSA Neutral Host Network (NHN) providing LTE radio access to multiple Participating Service Providers (PSPs).

R1-NHN-RSH-002 It shall be possible to organize a set of LTE CBSDs to provide LTE radio access to private network services.

R1-NHN-RSH-003 It shall be possible to configure a CBRSA NHN to provide different portions of available radio resources to each PSP based on business agreements.

R2-NHN-RSH-004 The identity of the CBRS Network is broadcast via System Information SIB1 by the CBRS RAN, and includes a PLMN-ID. The PLMN-ID may be a shared PLMN-ID assigned by the IMSI-Administrator for CBRS operators, or a PLMN-ID used by the operator.

R2-NHN-RSH-005 The Cell identity of the CBRS cell is broadcasted via System Information by the CBRS RAN, and shall be unique within any CBRS shared PLMN-ID.

R2-NHN-RSH-006 It shall be possible for the user to manually select the Participating Service Provider in a CBRS network.

R2-NHN-RSH-007 It shall be possible to authorize local breakout of all or some UE traffic.



10


5.1.1.2 CBRSA NHN RAN DISCOVERY REQUIREMENTS

R1-NHN-DIS-001 A CBRSA NHN shall broadcast system information that enables discovery of the NHN and associated PSPs.

5.1.1.3 CBRSA NHN AUTHENTICATION REQUIREMENTS

R1-NHN-AUT-001 A CBRSA NHN shall be able to cooperate with the PSP's network to support one or more of the following:

- authentication using USIM-based credentials.

- authentication using certificate-based credentials,

- authentication using Username/Password.

R1-NHN-AUT-002 A CBRSA NHN shall be capable to support one or more of the following:

- local authentication with an authentication server dedicated to the network,

- authentication using external authentication server(s).

R1-NHN- AUT-003 It shall be possible for a CBRSA NHN UE to support multiple authentication protocols.

R1-NHN- AUT-004 It shall be possible for a CBRSA NHN UE to establish a secure tunnel with a service provider’s ePDG using credentials associated with the service provider’s subscription.

R1-NHN- AUT-005 A Private Network and a CBRSA NHN that has its own subscribers shall be able to authenticate its own subscribers.

5.1.1.4 CBRSA NHN MOBILITY REQUIREMENTS

R1-NHN-MOB-001 A CBRSA NHN shall support mobility between the cells of the CBRSA NHN RAN per 3GPP specifications (intra-CBRSA NHN mobility).

R1-NHN-MOB-002 A CBRSA NHN shall support the continuity of PDN connections using handover procedures defined in 3GPP specifications from the NHN network to a PSP operator network (e.g., HO from a CBRSA NHN to a MNO with PDN continuity) and also from the PSP operator network into the NHN network.



11


5.1.1.5 CBRSA NHN GENERAL SECURITY REQUIREMENTS

This section provides requirements regarding the security aspects of a CBRSA NHN.

R1-NHN-SEC-001 A CBRSA NHN shall be capable of cooperating in the authentication of a device by the PSP’s core network.

R1-NHN-SEC-002 A CBRSA NHN shall be able to securely provide the KPIs to the PSP as per the mutually agreed security policies.

R1-NHN-SEC-003 A CBRSA NHN shall not disclose KPIs of a PSP to other PSPs.

5.1.1.6 CBRSA NHN MEASUREMENT REQUIREMENTS

The requirements in this section do not apply to Private Network use case.

R1-NHN-MES-001 A CBRSA NHN shall be capable of providing Key Performance Indicators (KPIs) to a PSP regarding the service and resources provided to the PSP.

R1-NHN-MES-002 A CBRSA NHN shall allow a PSP request to fetch KPIs per a mutually agreed SLA.

R1-NHN-MES-003 A CBRSA NHN shall provide individual and aggregated KPIs to the PSP per a mutually agreed SLA.

R1-NHN-MES-004 A CBRSA NHN shall be capable of providing byte counts of user data transmitted between the PSP and the UE in both uplink and downlink directions, within a pre-determined time period via the CBRSA NHN, to the PSP.

R1-NHN-MES-005 A CBRSA NHN shall support a minimum set of KPIs consistent with those specified by 3GPP per a mutually agreed SLA.

R1-NHN-MES-006 A CBRSA NHN shall support, per PSP, the KPI and counters related to Call/Session establishment Success Rate as specified by Accessibility KPI in [4] and by counters to calculate this KPI in [5].

R1-NHN-MES-007 A CBRSA NHN shall support, per PSP, the KPIs and counters as specified by Accessibility EPS Attach Success Rate KPI in [6] and by counters to calculate this KPI in [7].

R1-NHN-MES-008 A CBRSA NHN shall support, per PSP, the KPIs and counters related to Call / Session Drop rate as specified by Retainability KPI in [4] and by counters to calculate this KPI in [5].



12


5.1.2 MSO USE CASE

5.1.2.1 MSO SPECIFIC RAN REQUIREMENTS

R2-MSO-RAN-001 When a UE with 2 subscriptions – one subscription belonging to an MSO and another subscription belonging to an MNO enters the CBRS operator network deployed by the MSO, the UE shall be able to attach to the CBRS operator’s network using the MSO subscription for all non-voice PDN services. For all voice-based services including VoLTE, the UE shall be able to attach to the MNO operator’s network using the MNO subscription. The CBRS network architecture shall be able to support such a UE behavior.

5.1.3 FIXED WIRELESS NETWORK USE CASE

5.1.3.1 CBRSA FIXED WIRELESS NETWORK ACCESS ARCHITECTURE

REQUIREMENTS

R2-FWN-ARC-001 It shall be possible for a Fixed Wireless Network to enable interworking with another Service Provider's existing non-3GPP AAA for subscription authentication, authorization and accounting.

R2-FWN-ARC-002 A Fixed Wireless Network shall support network (Radio Access and Core Networks) sharing mechanisms for interworking with multiple SP.

R2-FWN-ARC-003 A Fixed Wireless Network shall support delegation of IP address allocation for the subscriber to the corresponding SP, including interworking with SP's AAA or DHCP server.

R2-FWN-ARC-004 A Fixed Wireless Network should be able to support multiple PDNs per UE (e.g., for separation of Internet and VoIP networks), as per 3GPP specifications.

5.1.3.2 CBRSA FIXED WIRELESS NETWORK ACCESS SERVICE REQUIREMENTS

R2-FWN-SVC-001 A Fixed Wireless Network should allow Over-the-Air service and

subscription activation based on 3GPP specifications (e.g. 3GPP TS 31.116) or

operator specific methods.



13


R2-FWN-SVC-002 A Fixed Wireless Network should enable Layer 2 data services (native Ethernet or IEEE

802.1q VLAN) to its end-users, including one or more of the following:

- Native Ethernet (untagged) user traffic

- Single or Multiple Point-to-Point VLAN services for the user

- Single or Multiple Point-to-Multipoint VLAN services for the user

R2-FWN-SVC-003 When providing Layer 2 services, A Fixed Wireless Network should provide native

wireless infrastructure QOS per user L2 data flow, classified by one or more of the

following fields:

- 802.1q VLAN Identity

- 802.1p priority bits

- IP-layer DSCP value

5.2 CBRS NETWORK FEATURE/FUNCTIONALITIES REQUIREMENTS

5.2.1 3GPP-BASED ACCESS MODE (NON-EPS-AKA)

5.2.1.1 GENERAL REQUIREMENTS

R2-XAU-GEN-001 It shall be possible for the service provider to provision an IMSI to the non-EPS-AKA subscription.

R2-XAU-GEN-002 A CBRS Network that supports 3GPP-based Access Mode (non-EPS-AKA) shall support all procedures as defined in 3GPP TS 23.401 with the ability of supporting non-EPS-AKA subscription for attaching the UE.

5.2.1.2 AUTHENTICATION REQUIREMENTS

R2-XAU-AUT-001 A CBRS Network that supports 3GPP-based Access Mode (non-EPS-AKA) shall support multiple non-EPS-AKA authentication mechanisms including EAP-TLS and EAP-TTLS.

R2-XAU-AUT-002 A CBRS Network that supports 3GPP-based Access Mode (non-EPS-AKA) shall be able to identify the UE based on the IMSI provided by the UE during the 3GPP-based Access Mode (Non-EPS-AKA) attach procedure.



14


R2-XAU-AUT-003 A CBRS Network that supports 3GPP-based Access Mode (non-EPS-AKA) shall be able to allocate GUTI at the end of an IMSI based successful initial attach using a non-EPS-AKA subscription.

5.2.2 UE REQUIREMENTS

R2-UEP-GEN-001 It shall be possible for a UE that is operating as defined in CBRS-Profile III, CBRS-Profile IV, or CBRS-Profile V to be able to support dual subscriptions – one USIM based subscription and another can be a USIM or certificate-based or username-password subscription (non-EPS-AKA).

R2-UEP-GEN-002 A UE that is operating as defined in CBRS-Profile III shall be able to maintain 2 EMM contexts (with independent PDN connections over active and inactive access network) using a single LTE radio access network connection and may have to perform all requisite session maintenance procedures like TAU even on the access network where it is in IDLE state.

R2-UEP-GEN-003 It shall be possible for the UE to support multiple authentication related mechanisms and protocols based on USIM, certificate, and username-password (e.g., EPS-AKA, EAP-AKA, EAP-AKA’, EAP-TLS, EAP-TTLS) and to store the credentials in the USIM or a secure location in the UE.

R2-UEP-GEN-004 It shall be possible for a UE that is operating as defined in CBRS-Profile V to be able to support dual USIM subscriptions or one USIM and one non-USIM subscription.

R2-UEP-GEN-005 A UE that is operating as defined in CBRS-Profile V shall be able to establish SWu [13] like tunnel for specific PDN services via the LTE network to which it is attached.

R2-UEP-GEN-006 A multi-subscription UE that that is operating as defined in UE-Profile III, UE-Profile IV or UE-Profile V, it shall be possible to provision a preferred operator (subscription and network) to which the UE shall always attach, whenever such operator network is available.

R2-UEP-GEN-007 If a preferred operator network is provisioned in a multi-subscription UE that is operating as defined in CBRS-Profile III, CBRS-Profile IV or CBRS-Profile V, the UE shall always attach to the preferred operator network using the credentials of the preferred operator and shall always use the credentials of the non-preferred operator to attach to the non-preferred operator network.

R2-UEP-GEN-008 In a multi-subscription UE that operates as defined in CBRS-Profile III, CBRS-Profile IV or CBRS-Profile V, it shall be possible to provision a policy such that some specific PDN services are always obtained using one of the subscriptions from the network of the operator pertaining to the subscription.

R2-UEP-GEN-009 When attached to the non-preferred operator network, it shall be possible for the multi-subscription UE that operates as defined in CBRS-Profile III or CBRS-Profile V, to



15


periodically perform background scanning to detect the presence of the preferred operator network.

R2-UEP-GEN-010 When a multi-subscription UE that is operating as defined in CBRS-Profile III, CBRS-Profile IV or CBRS-Profile V is attached to non-preferred operator network and detects the presence of the preferred operator network, it shall be possible for the UE to attach to the preferred operator network using the preferred operator credentials. However, when operating as defined in CBRS-Profile III or CBRS-Profile V such an attach procedure shall be done only when all PDN sessions are in IDLE state.

R2-UEP-GEN-011 When a multi-subscription UE that is operating as defined in CBRS-Profile III is attached to the preferred operator network, it shall be possible for the UE to answer the paging request for itself from non-preferred operator network.

R2-UEP-GEN-012 When a multi-subscription UE that is operating as defined in CBRS-Profile III or CBRS-Profile IV is attached to the preferred operator network, it shall be possible for the UE to attach to the non-preferred operator network in order to obtain the PDN services that are provisioned to use the non-preferred operator network only. In such an event, it shall be possible for the UE to move all other active PDNs to non-preferred operator network.

R2-UEP-GEN-013 When a multi-subscription UE that is operating as defined in CBRS-Profile V is attached to preferred operator network, it shall be possible for the UE to establish an SWu like tunnel with the non-preferred operator network in order to obtain the PDN services that are provisioned to use the non-preferred operator network only.

R2-UEP-GEN-014 When a multi-subscription UE that is operating as defined in CBRS-Profile III, CBRS-Profile IV or CBRS-Profile V is attached to a preferred operator network and moves beyond the coverage area of the preferred operator network, the UE shall attempt to attach to non-preferred operator network (if detected and supported, and not already attached) and it shall be possible to move all active PDN connections to the non-preferred operator network. The attach to non-preferred operator network can happen irrespective of the state of the PDN sessions.

R2-UEP-GEN-015 Whenever the preferred operator network is not available, it shall be possible for a multi-subscription UE that is operating as defined in CBRS-Profile III, CBRS-Profile IV or CBRS-Profile V to attach to a detected and supported non-preferred operator network using the non-preferred operator network subscription and obtain all PDN services from the non-preferred operator network.

R2-UEP-GEN-016 It shall be possible for a UE that is operating as defined in CBRS-Profile III, Profile IV or CBRS-Profile V to remember the network where it had successfully attached along with the respective subscription/credentials that the UE used to attach. A UE shall then use the same subscription for attaching to the same network whenever the subscriber visits the same network in the future. The subscription can be USIM or non-USIM and the credentials can be information related to the network (like PSP ID, NHN ID in case of CBRSA NHN) or information generated during the initial attach procedure (like GUTI).

R2-UEP-GEN-017 For a UE that is capable of supporting 3GPP-based Access Mode (non-EPS-AKA) or NHN Access Mode with non-USIM credentials, it shall be possible to securely store non-



16


USIM credential including IMSI, certificates, username/password, network preferences and mobility policy.

R2-UEP-GEN-018 It shall be possible for a UE that is operating as defined in CBRS-Profile III, CBRS-Profile IV or CBRS-Profile V to support multiple Access Modes.

R2-UEP-GEN-019 A multi-subscription UE that is operating as defined in CBRS-Profile III, Profile IV or CBRS-Profile V shall be able to establish PDN connections using the appropriate access mode [3GPP Access Mode (EPS-AKA), 3GPP-based Access Mode (non-EPS-AKA) or NHN Access Mode (using USIM or non-USIM credential)] based on subscription type.

5.2.3 TRAFFIC LBO REQUIREMENTS

5.2.3.1 TRAFFIC LBO ARCHITECTURE REQUIREMENTS

R3-TLB-ARC-001 The CBRS Network may support the Traffic Local Breakout (Traffic LBO) feature, by which it is possible to authorize and enable forwarding all or some UE traffic associated to a single PDN connection or multiple PDN connections to networks and/or applications in proximity to the RAN elements.

R3-TLB-ARC-002 For the CBRS Network to enable the Traffic LBO feature, the SP and the CBRS Network Operator shall jointly agree on services authorized for Traffic LBO.

R3-TLB-ARC-003 When the CBRS Network supports the Traffic LBO feature, the network element that enables traffic breakout shall support the 3GPP-defined procedures for mobility and session management, charging and lawful intercept.

5.2.4 ROAMING REQUIREMENTS FOR CBRS NETWORKS

5.2.4.1 ROAMING REQUIREMENTS FOR DATA ONLY SERVICES

The requirements in this section is applicable to all use cases where 3GPP Access Mode and 3GPP-based Access Mode (non-EPS-AKA) are used.

R3-ROM-DAT-001 Whenever a Visited LTE Network (CBRS or a non-CBRS Network) is deployed with an

intent to provide service to visiting subscribers that belong to other HNI based CBRS

Network operators, the LTE network shall interface with an appropriate function

(internal or external function) to determine the respective Home Network HSS based

on IBN, in order to authenticate and authorize the visiting subscriber.



17


R3-ROM-DAT-002 When the LTE Network (CBRS or a non-CBRS Network) communicates with an external

function to determine the respective Home Network HSS (based on IBN), such interface

shall comply with the Security requirements specified in GSMA Guidelines for LTE and

EPC Roaming (IR.88 [17]).

R3-ROM-DAT-003 A visited LTE Network (CBRS or a non-CBRS network) deployed with an intent to provide data services to visiting subscribers belonging to other SHNI based CBRS Network operators may enable Local Break-out of all or some of the visiting subscribers’ data traffic.

R3-ROM-DAT-004 A visited LTE Network (CBRS or a non-CBRS network)

that provide home routed data services to visiting subscribers of other SHNI based

CBRS Network operators shall establish the 3GPP/GSMA specified roaming interfaces

(e.g. S8 [9][17]) towards SHNI based CBRS Network.

R3-ROM-DAT-005 A Visited LTE Network (CBRS or a non-CBRS network) admitting subscribers belonging

to other SHNI based CBRS network operators may record KPIs and other counters

relevant to visited subscribers’ data that is offloaded to the visited LTE network.

SuchKPIs or counters may be provided to the SHNI based CBRS Network.

5.2.4.2 ROAMING REQUIREMENTS FOR IMS-BASED SERVICES The requirements in this section is in addition to the requirements in section 5.2.4.1 and are applicable when

providing Roaming support for IMS-Based services.

R3-ROM-IMS-001 When a CBRS Network supports IMS-based services, such as VoLTE, it shall follow relevant 3GPP specifications (TS 23.228 [18]).

R3-ROM-IMS-002 Roaming support for IMS-based services shall be provided by a Visited Network to

subscribers that belong to a CBRS Network Operator that uses the SHNI.

R3-ROM-IMS-003 void



18


APPENDICES (INFORMATIVE)

APPENDIX A: CBRS-PROFILE V BASED UE BEHAVIOR

A CBRS-Profile V based UE is a multi-subscription UE. In this example, the CBRS-Profile V based UE behavior is explained using subscription from 2 Operators – Operator 1 and Operator 2. The CBRS-Profile V based UE shall always attach to the Operator 1 network using the Operator 1 subscription and shall always attach to the Operator 2 network using the Operator 2 subscription. The UE is provisioned to prefer the Operator 1 network over the Operator 2 network. Policy that is provisioned in the UE will also ensure that some specific PDN services are always obtained using the Operator 2 subscription/network and the remaining PDN services will be obtained from the Operator 1 network whenever the Operator 1 network is available. When the Operator 1 network is not available, the UE will use the Operator 2 network for all PDN services. CBRS-Profile V based UE can come with both USIM subscriptions or one USIM subscription and another non-USIM (certificate based).

Figure A-1: Multi-subscription CBRS-Profile V Based UE example (Dual USIM Case)

In Figure A-1 above, the UE has a USIM subscription with Operator 1 and with Operator 2.



19


Figure A-2: Multi-subscription CBRS-Profile V based UE example

(USIM and non-USIM Subscription Case)

In Figure A-2 above, the UE has non-USIM subscription with Operator 1 and USIM subscription with Operator 2.

The behavior of the UE inside, outside and during transition to a CBRS network are as follows.

• While registered as an Operator 1 subscriber in a CBRS network:

o The UE may access the CBRS network operating in 3GPP Access Mode (EPS-AKA) or 3GPP-

based Access Mode (non-EPS AKA) based on the Operator 1 subscription.

o All services that are mapped to use the Operator 1 subscription are obtained using the CBRS

network (using the Operator 1 subscription) while in the Operator 1 CBRS network.

o In order to obtain services that are mapped to use the Operator 2 subscription and the

Operator 2 network, the UE shall establish an SWu tunnel with the ePDG of Operator 2. The

SWu tunnel will be established by UE via the Operator 1 CBRS network to which it is attached.

▪ Example: The CBRS-Profile V based UE may use the Operator 1 CBRS network access

(obtained using the Operator 1 subscription) to obtain voice services using the

Operator 2 subscription over S2b via Operator 2’s ePDG (LTE Calling).

• While outside Operator 1 coverage but within the Operator 2 network coverage:

o The UE uses the Operator 2 network and the Operator 2 subscription for all PDN connections.

o The UE scans in the background for availability of the Operator 1 network, except when in an

active voice call on the Operator 2 network.



20


o If a CBRS network is detected with the Operator 1 PLMN-ID, non-voice PDN connections are

moved to the Operator 1 CBRS network, while the UE continues voice on the Operator 2 network

using the Operator 2 subscription over S2b via Operator 2’s ePDG.



21


APPENDIX B: SHNI AND IMSI BLOCK

The Home Network Identifier (HNI) is part of the International Mobile Subscriber Identity (IMSI) and consists two fields: Mobile Country Code (MCC) and Mobile Network Code (MNC). The HNI represents an identification for the Public Land Mobile Network (PLMN) in a mobile network and therefore represents the identity of the Home Subscriber Subsystem (HSS) administering a subscription. The IMSI identifies the subscription corresponding to a UE and comprises the HNI (also known as the PLMN ID) and Mobile Subscriber Identity Number (MSIN). HNIs are assigned by an IMSI Administrator to qualifying mobile networks on the basis of their standing and eligibility to operate a mobile telecommunications network [16].

The Alliance of Telecommunications Industry Solutions (ATIS)’ IMSI Oversight Council (IOC) has set up guidelines for the IMSI Administrator to assign the HNI to IOC-approved Radio Technologies using the shared CBRS spectrum. These guidelines depart from the normal procedures used to determine eligibility of an operator to create unique and valid IMSIs for their subscribers by designating at least one SHNI for use by shared spectrum users who are not already in possession of their own HNIs. The ATIS IOC guidelines divide the MSIN into 2 parts – a 4-digit IMSI Block Number (IBN) and 5-digit User Identification Number (UIN). This partition of MSIN will allow for 10,000 Blocks of 100,000 unique IMSIs within a SHNI [15].

Figure B-1: The SHNI used in CBRS creates a need to route IMSIs to networks;

IMSI Allocation

The ATIS IOC has published guidelines [15] that provides the details on how the IMSI blocks can be procured by CBRS Network Operators. The flow diagram gives a brief overview of the process.



22


Figure B-2: A flow diagram detailing the IMSI Administrator’s role in assigning IBNs for use by CBRS operators who do not

possess their own HNI



23


APPENDIX C: REQUIREMENTS MAPPING - OLD VS NEW

In release 3, a numbering format for all requirements in this Technical Specifications was defined. As a result of this, all requirement numbers were updated. This section provides the mapping of old requirement to the new requirement.

C.1 REQUIREMENT NUMBERING FORMAT

Format => Rx-ABC-DEF-nnn, where

• x: defines the release number o 1 – for Release 1 o 2 – for Release 2 o 3 – for Release 3, etc.

• ABC: defines the use case or feature/functioanlity o “SPN” for Service Provider Use Case o “NHN”, for Neutral Host Network Use Case o “PRV”, for Private Network Use Case o “MSO”, for MSO Use case o “FWN”, for Fixed Wireless Network Use Case o “5NR”, for 5G NR Use Case o “UEP”, for UE Profile o “TLB” for Traffic Local Breakout o “ROM”, for Roaming Functionality o “XAU” for extended Authentication

• DEF: defines the sub-feature classification o “IMS”, for IMS o “DAT”, for DATA o “SEC”, for Security o “DIS”, for Discovery o “RSH”, for RAN Sharing o “MES”, for Measurement o “GEN”, for General o “ARC”, for Architecture o “SVC”, for Service o “GEN”, for Generic functionality

• nnn: a three digit number defining the requirement in the same category starting from 001

C.2 REQUIREMENT MAPPING Table C.2-1: Requirement Mapping



24


OLD Requirement # Release New Requirement #

RAN-Share-001 Release 1 R1-NHN-RSH-001



RAN-Meas-001 Release 1 R1-NHN-MES-001








RAN-Disc-001 Release 1 R1-NHN-DIS-001

RAN-Mob-001 Release 1 R1-NHN-MOB-001

RAN-Mob-002 Release 1 R1-NHN-MOB-002

Security-001 Release 1 R1-NHN-SEC-001



AUTH-001 Release 1 R1-NHN-AUT-001









MSO-RAN-001 Release 2 R2-MSO-RAN-001

UE-001 Release 2 R2-UEP-GEN-001














25









FWN-ARCH-001 Release 2 R2-FWN-ARC-001




FWN-SERV-001 Release 2 R2-FWN-SVC-001



NEPS-GEN-001 Release 2 R2-XAU-GEN-001

NEPS-GEN-002 Release 2 R2-XAU-GEN-002

NEPS-AUTH-001 Release 2 R2-XAU-AUT-001



LBO-ARCH-001 Release 3 R3-TLB-ARC-001



SR-ROAM-001 Release 3 R3-ROM-DAT-001





IMS-ROAM-001 Release 3 R3-ROM-IMS-001

IMS-ROAM-002 Release 3 R3-ROM-IMS-002



26


TABLE D-1: CHANGE HISTORY

VERSION DATE

(dd-mm-yyyy)

DESCRIPTION

V1.0.0 01-02- 2018 Release 1 of this Specification

V1.0.0 Rev 1

08-02-2018 Beginning of work for Release 2

Implemented NSTG-18-004

V1.0.0 Rev 2

26-02-2018 Beginning of work for Release 2

Implemented NSTG-18-004-r4

V1.0.0 Rev 3

02-04-2018 Implemented NSTG-18-031-r0 (Move UE Types to TS-1001)

Corrected implementation of NSTG-18-017.

Implemented NSTG-18-023 rev 4 (UE requirements)

V1.0.0 Rev 3.1

04-04-2018 Draft text for categories of 3GPP Access Mode

V1.0.0 Rev 3.2

09-04-2018 Implemented NSTG-18-039 (FWA requirements)

V1.0.0 Rev 3.3

17-04-2018 Implemented 3GPP Access Mode terminology agreed at the NSTG meeting on 2018-04-16.

V1.0.0 Rev 4.0

24-04-2018 Changes agreed on-screen during the meeting on 2018-04-23.

V1.0.0

Rev 5.0

08-05-2018 Implemented NSTG-18-056_r2(NSTG-18-051)_2018.05.08_Ruckus Networks_Technical_3GPP-Based

Access Mode (non-USIM) Stage 1

V1.0.0

Rev 6.0

14-05-2018 Implemented NSTG-18-063_r2(NSTG-18-057)_2018.05.21_Ruckus Networks_Technical_UE Enhancements for 3GPP-Based Access Mode (non-EPS-AKA) TS Stage 1

V1.0.0 Rev 7.0

11-06-2018 Implemented NSTG-18-066_r1_2018.06.04_Ruckus Networks_Technical_UE Types Modifications to TS Stage 1. This CR updates Section 3.3

V1.0.0

Rev 8.0

11-06-2018 - Implemented NSTG-18-071_r1(NSTG-18-067)_2018.06.11_Ruckus Networks_Technical_Additional

NHN Architecture Options for Stage 1 TS.

- Section 3.3 moved as section 5

- Updates to Section 3 & section 4.3



27


V1.0.0

Rev 9.0

11-07-2018 - Incorporated accepted comments from Meeting held on 9 Jul 2018 (Ref -> NSTG-18-083_r1 (NSTG-18-

081)_2018.07.09_Chair_TG_TS-1001 Comments)

- Incorporated all “Editorial” comments from Ballot Review (Ref -> NSTG-18-085_r2 (NSTG-18-

083)_2018.07.11_TS_Editor_TG_TS-1001 Comments)

V1.0.0

Rev 10.0

24-07-2018 - Incorporated accepted comments from Meeting held on 24 Jul 2018 (Ref -> NSTG-18-092_r3 (NSTG-18-081)_2018.07.24_Chair_TG_TS-1001 Comments.docx)

V1.0.0

Rev 11.0

22-08-2018 - Incorporated CR approved in meeting held on 20 Aug 2018 - NSTG-18-113_r1_2018.08.11_Ruckus Networks - Comcast - Charter - Federated - Nokia - Extenet_Technical_UE Profiles Enhancements.docx

V1.0.0

Rev 12.0

23-09-2018 - Incorporated accepted comments from NSTG-18-097_r8 (NSTG-18-081)_2018.07.27_Chair_TG_TS-1001

Comments.docx

- Incorporated NSTG-18-108_r0_2018.08.06_American Tower_Technical_TS1001 Section4.6 Fixed Wireless Networks.docx

V1.0.0

Rev 13.0

01-10-2018 - Implemented “accepted” comments as in NSTG-18-097_r9 (NSTG-18-081)_2018.07.27_Chair_TG_TS-1001 Comments.docx

- Implemented NSTG-18-125_r1_2018.09.26_Ericsson_Technical_Shared_HNI_AppB.docx

V1.0.0

Rev 14.0

03-10-2018 - Editorial modifications done throughout the document to enhance readability.

V2.0.0 16-04-2019 - Published version for Release 2.0

V2.0.0 Rev 1.0

30-08-2019 - Editorial modifications

o Update document per new OnGo template

o Improve readability

- Incorporated CRs

o NSTG-19-080_r0_2019.07.23_Ruckus Wireless_Technical_TS1 New Template.docx

o NSTG-19-038_r6_2019.04.08_Athonet_Technical_CR for TS 1001 on LBO.docx



28


o NSTG-19-049_r2_2019.05.01_Ruckus Wireless_Technical_Stage 1 Roaming

Requirements.docx

V2.0.0 Rev 2.0

15-10-2019 - Incorporated CRs

o NSTG-19-108_r1_2019.10.07_Athonet_Technical_IMS

roaming.docx

o NSTG-19-111_r3_2019.10.15_Ruckus_Technical_Roaming Text.docx

V3.0.0 Rev 3.0

03-12-2019 - Release 3 Ballot Review comments incorporated per NSTG-19-128_r1_(NSTG-19-120)_2019.12.09_Chair_TG_Comments for TS-1001 Rel 3.docx

V3.0.0 Rev 4.0

16-12-2019 - Release 3 Ballot Review comments: NSTG-19-120_r0_2019.11.18_Chair_TG_Comments for TS-1001 Rel 3_Rev 6.docx

- NSTG-19-134_r0_2019.12.16_Ruckus_Technical_NHN Roaming Text for TS1


cbrs network services use cases and requirements v3.0.0 18 ... · requirements may include network...

Documents