cbrsa-tr-0100 v1.0.0 identifier guidelines for shared hni

CBRSAlliance3855SW153rdDriveBeaverton,[email protected]©2018CBRSAllianceAllRightsReserved

CBRSAllianceIdentifierGuidelinesforSharedHNI

CBRSA-TR-0100

V1.0.0

November27,2018

mailto:[email protected]


LEGAL DISCLAIMERS AND NOTICES THIS SPECIFICATION IS PROVIDED "AS IS," WITHOUT ANY REPRESENTATION OR WARRANTY OF ANY KIND, EXPRESS, IMPLIED, OR STATUTORY; AND TO THE MAXIMUM EXTENT PERMITTED BY LAW, CBRS ALLIANCE, AS WELL AS ITS MEMBERS AND THEIR AFFILIATES, HEREBY DISCLAIM ANY AND ALL REPRESENTATIONS AND WARRANTIES, INCLUDING WITHOUT LIMITATION ANY WARRANTIES OF MERCHANTABILITY, TITLE, NON-INFRINGEMENT, FITNESS FOR A PARTICULAR PURPOSE, ACCURACY, OR RELIABILITY, OR ARISING OUT OF ANY ALLEGED COURSE OF PERFORMANCE, DEALING OR TRADE USAGE. ANY PERMITTED USER OR IMPLEMENTER OF THIS SPECIFICATION ACCEPTS ALL RISKS ASSOCIATED WITH THE USE OR INABILITY TO USE THIS SPECIFICATION. THE PROVISION OR OTHER PERMITTED AVAILABILITY OF OR ACCESS TO THIS SPECIFICATION DOES NOT GRANT ANY LICENSE UNDER ANY PATENT OR OTHER INTELLECTUAL PROPERTY RIGHTS ("IPR"). FOR MORE INFORMATION REGARDING IPR THAT MAY APPLY OR POTENTIAL AVAILABILITY OF LICENSES, PLEASE SEE THE CBRS ALLIANCE IPR POLICY. CBRS ALLIANCE TAKES NO POSITION ON THE VALIDITY OR SCOPE OF ANY PARTY'S CLAIMED IPR AND IS NOT RESPONSIBLE FOR IDENTIFYING IPR. TO THE MAXIMUM EXTENT PERMITTED BY LAW, UNDER NO CIRCUMSTANCES WILL CBRS ALLIANCE, OR ANY OF ITS MEMBERS OR THEIR AFFILIATES, BE LIABLE FOR DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, SPECIAL, EXEMPLARY, PUNITIVE, OR OTHER FORM OF DAMAGES, EVEN IF SUCH DAMAGES ARE FORESEEABLE OR IT HAS BEEN ADVISED OR HAS CONSTRUCTIVE KNOWLEDGE OF THE POSSIBILITY OF SUCH DAMAGES, ARISING FROM THE USE OR INABILITY TO USE THIS SPECIFICATION, INCLUDING WITHOUT LIMITATION ANY LOSS OF REVENUE, ANTICIPATED PROFITS, OR BUSINESS, REGARDLESS OF WHETHER ANY CLAIM TO SUCH DAMAGES SOUNDS IN CONTRACT, WARRANTY, TORT (INCLUDING NEGLIGENCE AND STRICT LIABILITY), PRODUCT LIABILITY, OR OTHER FORM OF ACTION.

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



Table of Contents 1. Introduction ...................................................................................................................11.1. Scope..............................................................................................................................................................11.2. References...................................................................................................................................................11.3. Glossary........................................................................................................................................................1

2. Goals .............................................................................................................................3

3. Problems with Non-Uniqueness for Key Identifiers .....................................................43.1. HNI..................................................................................................................................................................43.2. IBN(partofIMSI).....................................................................................................................................43.3. CBRS-NID–NetworkID.........................................................................................................................53.4. ECGI................................................................................................................................................................53.5. GloballyUniqueMMEIdentity(GUMMEI)[7].............................................................................63.6. PSP-ID(ParticipatingServiceProvider).........................................................................................73.7. TrackingAreaIdentity(TAI)[7]........................................................................................................8

4. Deployment Considerations ..........................................................................................84.1. SystemsNotNeedingUniqueness.....................................................................................................84.2. ProblemswithSelf-AssignedIdentifiers........................................................................................94.3. IdentityAdministrators.........................................................................................................................94.4. BusinessProcess....................................................................................................................................104.5. IdentifierManagementPrinciples..................................................................................................104.6. ProcessImplementation.....................................................................................................................11

Annex A. ECGI Uniqueness and E911 Detailed Rationale ...........................................13

Annex B. Revision History ............................................................................................15


Copyright©2018CBRSAlliance|AllRightsReserved

1

1. Introduction 1.1. Scope

SuccessfulbroaddeploymentofLTEnetworksinCBRSspectrumrequiresproperuseofLTEnetworkanddeviceidentifiers.

ThisdocumentisaTechnicalReportthatisintendedforCBRSLTEoperatorsthatwillbeusingaSharedHNIandnotforoperatorsthathavetheirownHNI.

ThesubjectofthisdocumentisanetworkbasedonCBRSAlliancespecifications[2][6]thatusesaSharedHNI(SHNI)astheCBRS-I.Suchanetworkdeploymentisreferredtoasa“SHNINetwork”inthisdocument.

1.2. References

[1] ATISIOC.IMSIGuidelinesforSharedHNIforCBRSRange,http://www.atis.org/01_committ_forums/ioc/Docs/IMSI-CBRS-Guidelines.pdf

[2] CBRSAlliance.NetworkServicesStage2and3Specifications.CBRSA-TS-1002.

[3] MulteFireAlliance.ArchitectureforNeutralHostNetworkAccessModeStage2.MFATSMF.202.

[4] 3GPP.Non-Access-Stratum(NAS)protocolforEvolvedPacketSystem(EPS);Stage3.TS24.301.

[5] GSMAEmbeddedMobileGuidelines–NetworkAspects,Version3.https://www.gsma.com/iot/wp-content/uploads/2012/03/GSMA-Whitepaper-Embedded-Mobile-Guidelines-Release_3-Network-Aspects1.pdf

[6] CBRSAlliance.NetworkServicesUseCasesandRequirements.CBRSA-TS-1001.

[7] 3GPP.Numbering,addressingandidentification.TS23.003.[8] 3GPP.S1ApplicationProtocol(S1AP).TS36.413.

[9] MulteFire.Non-Access-Stratum(NAS)protocolforEvolvedPacketSystem(EPS);Stage3.MFATS24.301.

1.3. Glossary

Term Definition

BSSID BasicServiceSetIdentifier

CBRSA CBRSAlliance.http://cbrsalliance.org

CBRS-NID CBRSNetworkID(27bits).

http://www.atis.org/01_committ_forums/ioc/Docs/IMSI-CBRS-Guidelines.pdf

https://www.gsma.com/iot/wp-content/uploads/2012/03/GSMA-Whitepaper-Embedded-Mobile-Guidelines-Release_3-Network-Aspects1.pdf

https://www.gsma.com/iot/wp-content/uploads/2012/03/GSMA-Whitepaper-Embedded-Mobile-Guidelines-Release_3-Network-Aspects1.pdf


Copyright©2018CBRSAlliance|AllRightsReserved 2

CSG ClosedSubscriberGroup.GSM/LTEconceptre-usedbyCBRSAasCBRS-NID.See[2]and[7].

DSC DiameterSignalingController

ECGI E-UTRANCellGlobalIdentifier,composedofHNI+MacroeNBID(20bits)+CellID(8bits).See[8].

ESQK EmergencyServicesQueryKey

GUMMEI GloballyUniqueMMEID(48bits).

HNI HomeNetworkIdentifier:MCC+MNC(6decimaldigits1).

IBN IMSIBlockNumber(4decimaldigits).

IMSI Subscriptionnumber(15decimaldigits).,see[7].ForSharedHNI:SHNI+IBN+UIN,see[1].

IMSI-A USIMSIAdministrator.http://imsiadmin.com

MCC MobileCountryCode(3decimaldigits).AssignedbyITU-Ttoacountry

MME MobilityManagementEntity

MMEC MMECode(8bits)

MMEGI MMEGroupID(16bits)

MMEI MMEID=MMEGI+MMEC

MNC MobileNetworkCode(2-3decimaldigits).AssignedbynationalIMSIadministratortooneoperatoror,inthecaseofSharedHNI,tomultipleCBRS-Ioperators

PLMN-ID SynonymforHNI.

PSP-ID ParticipatingServiceProviderID.HNI,OID,domainnameora24bitreductionofalongeridentifier

1 Decimaldigitsareencodedas4-bitBCDunlessotherwisespecified.

http://imsiadmin.com



SHNI SharedHNI.AnHNIdesignatedbyATISIOCforCBRSoperationthatisrecognizedbyCBRSsystemsasshared.Thefirstsuchassignmentis315-010.

SHNINetwork

AnetworkthatbroadcastsaSharedHNIasitsidentity(supplementedbyaCBRS-NIDforuniqueness).

TAC TrackingAreaCode(16bits).

TAI TrackingAreaIdentity.SHNI+TAC

UIN UserIDNumberwithinIMSI(5decimaldigits).

2. Goals OneofthepurposesoftheCBRSAllianceistocoordinatetheequipmentandactivitiesofmanufacturers,operators,SASprovidersandotherparticipantsintheCitizensBroadbandRadioService(CBRS)sharedspectrumecosystem,tospeedtimetomarket,reducecost,andincreasethereliabilityandinteroperabilityofsystemsbasedonLTEstandards.OneofthewaysthesegoalscanbeaccomplishedisthroughthedevelopmentofspecificationsorguidelinesspecificallyorientedtooperationintheCBRSspectrumthatarenotaddressedby3GPPorotherorganizations.Thisdocumentpresentsbackgroundinformationandrecommendationsrelatedtothecoordinationofthefollowingimportantidentifiersfornetworkanduserequipment(UE),andexplainswhytheybenefitfrombeinggloballyorlocallyunique:

• SharedHNI.Aspecificcombinationof3-digitMobileCountryCode(MCC)and3-digitMobileNetworkCodethatindicatesthatthenetworkisusingaSharedHNI(SHNI).Thiscodeissharedbymanyoperators,andisthereforenotuniquetoasingleoperator.Atpresentthereisjustonesuchnumber(315-010),buttherecouldbemoreinthefuture.

• CBRS-NID.TheNetworkIDisbasedontheLTECSG-ID(ClosedSubscriberGroupID)andsupplementstheSharedHNI.TogethertheycanprovideagloballyuniqueidentityforasingleSHNINetwork.

• IMSI.AnIMSIisthe15-digitgloballyuniquewirelesssubscriptionidentityandisstoredintheSIM/UICCinsertedorembeddedinaUE.FordevicesprovisionedforanSHNINetwork,theSharedHNIwillbeusedintheIMSIasMCC+MNC.DeviceswithanIMSIbasedonanon-sharedHNIthatroamintoanSHNINetwork(e.g.NHN)couldcontinuetousetheirexistingIMSI[7].

• E-UTRANCellGlobalIdentifier(ECGI).EveryLTEbasestation(eNodeB)isintendedtobeuniquelyidentifiedbyanECGIthatiscomposedofPLMN-IDandCellID.FortheCBRSNetwork,theSharedHNIisusedasthePLMN-IDwithintheECGI[7].



• MMEID(GUMMEI).EveryMobilityManagementEntityinanLTEsystemrequiresagloballyuniqueMMEID.BecauseitcontainstheSharedHNIasaprefix,GUMMEIvaluesmustbecoordinatedwithintheSharedHNI[7].

• TrackingAreaID(TAI)needstobelocallyunique,withnoneighboringsystemsusingthesamevalue[7].

Uniqueidentifiersareimportantincommunicationssystemsbecausecommunicationsystemsoftendonotfunctioncorrectlywithduplicateidentifiers.Forexample,itispossiblethattwomobiledeviceswiththesameIMSIwillnotworkproperlyandeventuallybothmaybeblacklisted(unabletoreceiveservice)afterfailingauthentication.Similarly,hardwareidentifierslikeIMEIarerequiredtobegloballyunique.

3. Problems with Non-Uniqueness for Key Identifiers ThissectionexaminestheuniquenessrequirementsofseveralkeyidentifiertypesthatareessentialtotheoperationofCBRSLTEnetworks.

3.1. Home Network Identifier (HNI)

NormallyanHNIisassignedtoasingleoperator,andtheoperatorisresponsibleformanagingtheuniquenessofIMSIcodesandotheridentifiersconstructedusingtheHNI.However,ATISIOChasmadeitpossibleforthenewSharedHNItobeusedsimultaneouslybyalargenumberofoperatorsintheCBRSecosystem.Coordinationoftherelevant“CBRSSharedHNI”identifiersdescribedinthisdocumentwillbeadministeredbytheCBRSAlliance[1].

3.2. IMSI Block Number (IBN)

EverysubscriberhasanIMSIstoredwithintheir‘smartcard’(UICC)orembeddedinthedevice(eUICC).Itisthe15-digitgloballyuniquewirelesssubscriptionidentityconsistingofHNI+MSIN(MobileSubscriptionIdentificationNumber).NormallyanoperatorisassignedanHNIforexclusiveuse,andisresponsibleforassignmentoftheMSINcodestosubscribers.

However,foraSharedHNI(SHNI),MSINisfurtherbrokendownintoIBN+UIN.ACBRSoperatorthathassubscribers(i.e.‘smartcards’orUICCforeachsubscription,whetherremovableorembedded)isresponsibleforobtainingatleastoneIBNfortheirexclusiveuse.TheSharedHNI+operator-specificIBNthenformsagloballyuniqueoperatoridentifier.

TheCBRSoperatorisresponsibleforcreatinguniqueidentifiersbyallocatingadifferentUINtoeachsubscriber/subscription.IftheCBRSoperatorfailstoobtainanoperator-specificIBNforitssubscribers,thentheglobaluniquenessoftheirIMSIsisnolongerguaranteed,andthefollowingproblemscanoccur:

• AuthenticationofthesubscriptionwillfailifthewrongMMEisqueriedbasedonthenon-uniqueIMSI.

• NetworkoperationswillfailwhentheIMSIisusedtoroutemessages(e.g.toanMME).



3.3. CBRS-NID – Network ID

TheCBRS-NID(theLTEClosedSubscriberGroupID,CSG-ID)isessentiallyanextensiontotheSharedHNIthatcreatesacomposite,globallyunique,operatoridentity.TheuseofCSG-IDasCBRS-NIDisdescribedin[2].

TheCBRSAllianceplanstomaintainaregisterofCBRS-NIDcodesandensurethatanysinglecodeisonlyeverassignedtoasingleoperator2,thusachievingglobaluniquenessamongoperatorsusingtheCBRSAllianceCBRS-NIDcodes.

Ifanon-uniqueCBRS-NIDisusedbyonenetwork(Network‘B’)thatisthesameastheCBRS-NIDassignedtoanothernetwork(Network‘G’)thenamobiledevicefromNetwork‘G’encounteringNetwork‘B’canattempttoregisteronthisnetwork,andthemobile’sregistrationwillberejectedbyNetwork‘B’withe.g.,aCauseValueof3(IllegalUE)or8(EPSservicesandnon-EPSservicesnotallowed).ThemobilewillthenconsideritsUSIMasinvalid(see3GPPTS24.301[4]section5.3.7bandthemobilewillnotattempttoregisterwhenitlaterencountersitsownNetwork‘G’.Themobilewouldreturntonormalafterapowercycle,whentheUSIMisreplaced,orwhentimerT3245inthedeviceexpires(upto48hours)[4][5].

Toavoidthisproblem,CBRSAllianceTS-1002[2]recommendsusingCauseValue12(TrackingAreanotallowed)whenanATTACHREJECT,TRACKINGAREAUPDATEREJECTorSERVICEREJECTissenttoaUE.ThiswillallowtheUEtobeginanormalattachprocedureatalatertime.

Unfortunately,anunassociatedoperator,outsideoftheAlliance,couldusetheCBRSSharedHNIwithoutcoordinationwiththeAllianceandmightselectaNIDthathasbeenassignedtoanetworkbytheCBRSAlliance.TheCBRSAlliancewilltakeappropriateeffortstoavoidconflicts,e.g.,byfacilitatingtheassignmentofNIDsusedbynon-CBRSAlliancemembers.

3.4. EUTRAN Cell Global Identifier (ECGI)

TheECGIisagloballyuniqueidentifierforanLTEcellorsector,comprisedofHNIandCellIdentity.CellIdentityincludestheMacroeNBID.SeerequirementRAN-Share-005[6].TheECGIwillnotdistinguishbetweenmultipleCBSDsthatbroadcastthesamesystemparameters[7][8].DuplicateECGIsindifferentoperatornetworkscancausethefollowingproblems:

2 CBRS-NIDcodesshouldnotbere-used.Inthefuture,theIMSI-AmayassignadditionalHNIcodesandthereis

nowaytocorrelateNID(CSG-ID)withaspecificHNIwithinSIB-1.

9

MCC(3d) MNC(3d) IBN(4d) UIN(5d)

SHNI(6d) MSIN(9d)

IMSI(15d)



• BrokenLTEAssumption.LTEspecificationsarebasedupontheassumptionthatECGIisgloballyunique.ItisimpossibletoruleoutthepossibilitythatproblemswilloccurwithduplicateECGIthatwerenotknowntotheauthorsofthisdocument.Thosethatareknownarelistedbelow.

• ErroneousE911callroutinganddispatch.Traditionally,adatabaseofECGIsismaintainedtoprovideanapproximatelocationandblocksofPSAProutingnumbers(ESQK)for9-1-1callswhenaGPSlocationisnotavailable(orbeforeaGPSlocationisavailable).DuplicateECGIscouldresultinthewronglocationorwrongroutingnumberbeingprovidedtothe9-1-1calltakersatthePSAPifthirdpartyorsharedinfrastructureisusedtointerprettheECGI.GiventhecomplexityofroutingtoE911PSAPsitismostlikelythattheconversionfromECGItoapproximatelocationtoroutingnumberisdonebyathirdparty.

• SloworinaccurateGPSpositioning.GPSpositioningsignificantlybenefitsinspeedandaccuracyfromaninitial‘reference’location(accuratewithinafewmiles)thatisnormallybasedontheknownlocationofeachbasestationasidentifiedbyanECGI.Widelyusedlocationbasedapplications(e.g.mappingandnavigationapps)relyonaglobaldatabaseofECGIheldbyathirdparty.ThroughtheuseoftheOMASUPLprotocolandthisdatabase,theECGIistranslatedtoareferencelocation(e.g.towerlatitudeandlongitude),withoutoperatorknowledgeorintervention.

• FailuretomeetE911Mandates.GPSlocationisusuallyusedindispatchingE911calls,andhastimingandaccuracyrequirementsimposedbytheFCC.FailuretoachievetheserequirementsonaregularbasisbecauseofduplicateECGIinformationcouldconstituteaviolationofFCCrulesforoperatorsthatarewithintheE911mandates.

• BillingandAccountingProblems.ECGIsarenormallyprovidedinbillinginformationrecordsproducedbytheAAA.Whileitwillprobablynotcausebillingtothewrongcarrier,itcouldcauseconfusionoverthelocationofthecallwhentherecordsarebeingexaminedforvariouspurposes,includinglegal.

• DifficultyIdentifyingInterference.ECGIsmaybeusedtoidentifyanoperatorwhentryingtolocatethesourceofaninterferingsignal.AnECGIthatisduplicatedwillmakethismoredifficult.

• RFMeasurementExchangeDifficulties.TheuseofuniqueECGIscouldfacilitateexchangeofmeasurementinformationbetweenCBRSAlliancesystems.

3.5. Globally Unique MME Identity (GUMMEI) [7]

TheMMEIdentity(MMEI),inconjunctionwiththeSharedHNI(MCC+MNC),uniquelyidentifiesaMobilityManagementEntity.Lackofuniquenesscouldpreventoperatorsfrom

MCC(3d) MNC(3d) MacroeNBID(20b)

SHNI(6d/24b)

8b

CellIden<ty(28b)

ECGI



supportingroamingoftheiruserstootherSHNINetworks,asinformationrelatedtoroamingdevicescouldnotberoutedtotheappropriateMME.SpecialroutingequipmentknownasaDiameterSignalingController(DSC)couldbeneededtoreceiveDiametermessagescontainingtheIMSIoftheUE(e.g.anattempttovalidatetheUEbyaroamingpartner)andusetheIBNwithintheIMSItodeterminethenetwork,andthentheassociatedMMEGI.

MMEGroupIDuniquenessisrequiredifmultipleMMEsareusingthesharedHNI.

3.6. Participating Service Provider (PSP-ID)

IfNeutralHostNetwork(NHN)servicesareprovided,thesystemmustbroadcastalistof24-bitPSP-IDstoidentifyoperatorswhosesubscribersareallowedtoaccessserviceontheSHNINetwork.PSP-IDscomeinfourtypes,thatoriginatefromdifferentassignmentprocesses:

1. HNI(PLMN-ID).6decimaldigits(24bits)formedastheBCDdigitsofMCC+MNC(HNI).2. 24-bitOID.OnetypeofOIDknownasOUIis24bitsinlength.See:http://standards-

oui.ieee.org/bopid/opid.txt3. OtherOID.AnOIDlongerthan24bitsisusedtocreatea24-bitPSP-IDusingtheSHA-

256hashingalgorithm.4. Domainname.Thedomainnameisusedtocreatea24-bitPSP-IDusingtheSHA-256

hashingalgorithm.

TheCBRSsystemalsosupportsthreedifferentvaluesof‘bssid’toindicatethetypeofPSP-ID:

• 03:ff:ff:ff:ff:ffindicatestype1(HNI).• 03:ff:ff:ff:ff:feindicatestype2(24bitOID).• 03:ff:ff:ff:ff:fdindicatestype3or4(longeridentifierhashedto24bits).

Type1PSP-IDswillbeuniqueiftheHNIisunique,butwouldnotbeuniqueif,forexample,thePSPwasanotherCBRSoperatorusingtheCBRSHNI.

Type2OIDPSP-IDswillalsobeuniqueaslongasaunique24bitidentifierisobtainedfromIEEE.Types3and4(24bithash)willnotbeguaranteedtobeunique.

Anon-uniquePSP-IDcouldresultinadeviceattemptingtoaccessanetworkandbeingrejected.Thiscouldresultinperiodoftime(e.g.severalminutes)duringwhichtheUEmightnotattempttoaccessothersystemsforwhichitisauthorized(seesection5.3.7MF1of[9]).

12

MCC(3d) MNC(3d) MMEGI(16b) MMEC(8b)

MMEI(24b)SHNI(6d/24b)

GUMMEI(48b)

http://standards-oui.ieee.org/bopid/opid.txt

http://standards-oui.ieee.org/bopid/opid.txt



3.7. Tracking Area Identity (TAI) [7] TheTrackingAreaIdentity(TAI)isusedtocoordinatebetweenneighboringCBRSLTEsystems.WhenusingaSharedHNI,operatorsneedtocoordinatetheTAI.TheTAIiscomposedoftheHNIplusa16-bitTAC(TrackingAreaCode).IfaUEisrejectedwhenpresentingaTAItothenetwork,theUEmightnotattempttoaccessanynetworkbroadcastingthatTAIforaperiodoftime(e.g.severalminutes;seesection5.3.7MF1of[9]).Therefore,itisimportantthatTACcodes(theonlyuniquepartoftheTAIwithinaSharedHNI,i.e.SHNI)arecoordinated.Insituationswherecoordinationisnecessary,itcanbedonebyneighboringCBRSoperators.NocoordinationwithMNOsisnecessary,becausetheyuseaTAIbasedontheirowndistinctHNI(notSHNI).

TheTrackingAreaCodeisassignedbytheoperator,notbytheCBRSAlliance,andneedstobelocallyunique(i.e.notusedbyanyothernearbynetworkbroadcastingSHNI).ThefullTAIformatisSHNI(6d/24b)+TAC(16b).TheCBRSAlliancerecommendsthefollowingmethodtodefine6TACcodesthatwillproduceTAIcodesthatwillnotconflictwithanyotherSHNINetworkusingthesamemethod:

1. ThefirstTACisthe16bitbinarycodeforthenumericvalueofthenetwork’sassignedIBN.3

2. Thiscodeplus10,000.3. Thiscodeplus20,000.4. Thiscodeplus30,000.5. Thiscodeplus40,000.6. Thiscodeplus50,000.

4. Deployment Considerations 4.1. Systems Not Needing Uniqueness

ItmaybethatsomeCBRSLTEsystemswillnotneedidentifieruniquenessbecausewheninstalledtheymayhavemostorallofthefollowingcharacteristics:

• TheonlyCBRSsysteminageographicalarea.• Donotacceptincomingcalls.• DonotprovideroamingorNeutralHostNetworkservices.

3 NotethattheIBNisusuallyencodedasBCD,inwhichcase9999wouldbebinary1001100110011001.However,theTACshouldbeencodedasabinaryinteger,so9999wouldbebinary0010011100001111.

16

MCC(3d) MNC(3d)

SHNI(6d/24b)

TAI–TrackingAreaIden=ty(40b)

TrackingAreaCode(TAC–16b)


• Donotallowoutboundroamingbytheirownsubscribers.• ArenotrequiredtoprovideE911service.• Donotsupportthirdpartylocation-enabledapplications.• Havenootherneedforuniqueidentifiers.

However,thesecharacteristicsmaywellchangeovertime,andintheworstcase,couldrequirelaterrenumberingofthenetwork,thereplacementofeverySIMcard,communicationandcoordinationwiththirdpartynetworkelementsforroamingandcharging,changingtheidentificationofeverycell,andsoon.Also,devicesfromanetworkwithnon-uniqueidentifierscouldattempttoregisteronanothernetworkwiththesameCBRS-NID(notrealizingitisroaming),failregistration,thenbeunusableforaperiodoftimeevenbackonthehomenetwork.Similarly,thesenetworkswithnon-uniqueidentifierscouldimpactdevicesfromothernetworks.Thesmalleffortofensuringidentifieruniquenessmightnotprovideanimmediatebenefit,butcouldpreventamuchlargereffortinthefuture.

4.2. Problems with Self-Assigned Identifiers

Someproblemswithsettingasideaself-assignedblockofidentifiersare:

• OperatorsmayhavenochoicebuttoassignuniqueIMSIandCBRS-NIDcodes,inwhichcaseself-assigningMMEGroupIDsandECGIsarelikelyunnecessaryif,forexample,theCBRSAllianceautomaticallyassignsablockofMMEGroupIDsandECGIswitheveryNetworkID.

• Operatorsthatdonotwanttocoordinatecannotbereliedupontoproperlyconfiguretheiridentifiersintheself-assignedaddressspace,andmaystillconflictwithlegitimatelyassignedidentifiers.

• Eveniftheself-assignedaddressspacesarelarge,conflictsmaybemorelikelythanexpected(e.g.ifmultiplecarriersassignECGIsinsequencestartingwithzero).

• LossofaportionoftheaddressspaceforCBRSAAdministration(50%ifthefirstbitisusedtodistinguishedbetweenmanagedandself-assignedaddresses).

4.3. Identity Administrators

ResponsibilityforadministeringidentifiersimportanttoCBRSAlliancemembersissharedbetweentheUSIMSIAdministratorandtheCBRSAlliance,asshowninthetablebelow.

ThisdoesnotconsideroperatorswhodonotuseCBRSAlliancecoordinationservices.

ForidentifiersthatareallocatedbytheIMSIAdministrator(IBNandSharedHNI)theCBRSAlliancedatabasemaystillneedtostorethisinformation,atleastforsomeoperators.

Identifier AssignedbyIMSIAdministrator

AssignedbyCBRSA

AssignedbyCBRSoperator

Identifies Quantity

IMSI MCC+MNC(SHNI)+IBN

n/a UIN Subscription 10,000IBNx100,000UINperSHNI

CBRS-NID ––– CBRS-NID ––– Network 227


GUMMEI SHNI MMEGI MMEC MME 216MMEGIx28MMECperSHNI

ECGI SHNI MacroeNBID

CellIdentity Cellorsector 220ECGIx28CellIdentityperSHNI

TAI/TAC ––– ––– TAC Network(locally)

65534perregionofoverlap

4.4. Business Process

IfanoperatorofoneormoreSHNINetworksneedsIMSIcodes(i.e.willhaveUEshomedontheSHNINetwork)itcanobtainoneormoreIBNs(IMSIBlockNumbers)fromtheUSIMSIAdministrator[1].OneIBNcanbeusedforanynumberofnetworkscontrolledbythesameaccount(e.g.CBRSoperator).TheseIMSIcodeswillbeallocatedfromaSharedHNIdesignatedbytheIMSIAdministratorforthispurpose.

ItisbeneficialtoallindustryparticipantsthatCBRS-NID,MMEGIandECGIareobtainedfromtheCBRSAlliance.AnyorganizationwishingtobeassignedidentifiersforusewithanSHNINetworkmustfirstestablishanaccountalongwithalistofcontactpersonnelwhoareauthorizedtoobtainidentifiersonbehalfoftheorganization.OneaccountcanbeusedtoestablishanynumberofSHNINetworks.

ToobtainanassignmentoftheidentifiersneededforasingleSHNINetworktheaccountholderwillhavetorequestanassignmentofthefollowingfromtheCBRSAllianceforeachnetwork:

• AsingleCBRS-NID.ThisnumberwillbebroadcastintheCSG-IDfieldofSIB1[7]touniquelyidentifytheSHNINetwork(astheSharedHNIthatisalsobroadcastisnotsufficienttoidentifythenetwork).

• OneMMEGroupID.SinceoneMMEGroupIDcanbeusedtocreate256uniqueGUMMEIitisunlikelythatmorethanonewillbeneededbyanSHNINetworkbutifneeded,morethanonecanbeallocatedtoanetwork.

• OneormoreMacroeNBIDs.ThesizeandconfigurationofthenetworkwilldictatethequantityofMacroeNBIDsrequired.

• OneormoreIBNs.AssignedbytheUSIMSIAdministrator,butmaybevoluntarilystoredintheCBRSAdatabase,alongwiththeCBRSAassignedidentifierstofacilitateroaming.

4.5. Identifier Management Principles

CBRSAlliancewillcarefullymanagetheidentifierstoensurethatthelimitedsupplylastsformanyyearsbasedonthefollowingprinciples:

• VerifythatanewaccountisaCBRSoperator.• Verifythatthequantityofnumberingresourcesrequestedisreasonable.


• KeepincontactwiththeCBRSoperatortoregularlyverifythattheassignedcodesareinuse.

• Reclaimcodesthatarenolongerneeded.• EducatetheCBRSindustryontheneedforidentifiercoordination.• DocumenttheassignmentsofSHNIandIBNcodesprovidedtotheCBRSAlliance.• CoordinatetheassignmentandmanagementofNID,ECGIandMMEGIcodes.• MonitorIBNassignmentswithinCBRSSharedHNI(s)andcoordinateasneeded.

4.6. Process Implementation

AssignedidentifierswillbestoredinadatabasewithawebinterfaceforCBRSAllianceidentifierassignments.Therelationshipsbetweentheelementsofthissystemareshownbelow.

Onceanaccounthasbeenapproved,anyoftheapprovedcontactsfortheaccountcanobtainassignmentsofthethreetypesofidentifiersmanagedbytheCBRSAlliance.Thesystemwillalsoallowaccountstoreviewtheircurrentassignmentsofcodes,andwillgenerateanannualinvoiceforallassignedcodes.

NotethattheIMSIBlockNumbers(IBN)willbeassignedbytheUSIMSIAdministrator(IMSI-A).Onthatbasis,adatabaseofIBNmaynotbeneededtobemaintainedbytheCBRSA.However,iftheIMSI-Adoesnotprovideaneasilyqueriedandcurrentlist,orifreal-timequeriesareneeded,thismayneedtobemaintainedbytheCBRSA(directlyorviaanauthorizeddatabaseprovider).

Contact•  Loginname• Userid

IMSIBlock•  IBN

Network•  CBRS-NID

MMEGroup• MMEGI

Cell/eNodeB•  ECGI

Account•  CBRSacct#

SharedHNI• MCC+MNC

MMECode

Cellnumber

IdenGfierandotherObjectRelaGonships

CBSD

Administrator

IMSI-A

CBRSA

Operator


Similarly,theSharedHNIisassignedbytheIMSI-A.However,toallowthepossibilityofmultipleSharedHNIassignmentsinthefuture,atablecouldbemaintainedbyCBRSA,althoughatfirstthetablewillhaveonlyoneentry.


Annex A. ECGI Uniqueness and E911 Detailed Rationale

GeographicallocationisanimportantcomponentofEmergencyCalling(E911inNorthAmerica)thatprovidestwobasiclocation-relatedfunctions:

• IdentifyingtheappropriatePublicSafetyAnsweringPoint(PSAP)toreceivethecall(e.g.town,city,county,highwaypatrol).

• Identifyingtheaccuratelocationfordispatchofpublicsafetyassistance(ambulance,policecar,etc).

Geographicallocationcanmostrapidlybeprovidedbyusingtheservingcelllocation(e.g.towerlatitude,longitudeandperhapsaltitude),butthismaybeinaccuratebyseveralmilesinamacrocell.GPSlocationismuchmoreaccurate(severalmeters)buttakeslongertoobtain.Therefore,giventhatUSFCCE911mandatesrequirebothspeedandaccuracy,thePSAPisgenerallyidentifiedusingcelllocation(forspeed)anddispatchofanemergencyvehicletypicallyusesGPSlocationmethods(foraccuracy,sincedispatchisusuallyinitiatedseveralsecondsorevenminutesafterthecallisconnectedtothePSAP).

VariousspecificationsindicatethatattimestheCellID(ECGI)isusedtodeterminethelocationofamobile,anddependingonthenetworkarchitecture,thismayrequiretheECGItobegloballyunique:

• 3GPPTS23.167indicatesthat,inscenarioswheretheIMScoreneedstoretrievethelocationinformation,theCellID(ECGI)isincludedintheSIPinvitesenttotheemergencycallansweringcenter(PSAP).

• 3GPPTS23.167alsostatesthat,“Locationisindicatedinnetworkterms,forexampleusingtheglobalcellid[ECGI]incellularnetworks…”.

• ATIS-0700015.v003statesthatthelocationforIMS-basedE911maybebasedontheCellID.IftheLRForLocationServerareoutsidetheCBRSsystemthentheECGIwouldneedtobegloballyunique.

Leveragingnationalcross-referencetablesofECGIandgeographicalcoordinates,andtheydoformacro-cells,ECGIisusedtoderivethecelllocation(e.g.actualtowerlocationorapproximategeographiccenterofthecoveragearea)inLTEsystems.Ifthisconversionisdonewithinanoperator’snetwork,forbothPSAProutinganddispatch,theECGIonlyneedstobelocallyunique.Fromthisapproximatelocation,theEmergencyServiceslocationserverwillobtainatemporaryroutingphonenumber(ESQK)thatcanbeusedtobothroutethecalltothecorrectPSAPandprovideakeyforthePSAPtoobtainthenowstoredapproximatelocationinformation.Itislikelythatthisfunctionwillbeoutsourcedduetotheneedtomaintainapoolofphonenumbersforeveryansweringpoint.TheECGIisalsoimportantforGPSingeneral(notjustE911)becauseitprovidesthereferencelocationtomakeGPSfixesfasterandmoreaccurate.ThisrequiresacrossreferencefromECGItotowerlocation,whichrequiresuniquenessoftheECGIifthetableismaintainedbyathirdparty.Itisknownthatindustry-widecrossreferencesaremaintainedbyseveralorganizations,includingGoogle,inordertosupportSUPL-basedlocationservices.TheSUPLprotocol


transmitstheECGIfromthephonetotheserver(e.g.supl.google.com),notthecelllocation.SUPLserversaregenerallymaintainedbyphoneorphoneOSmanufacturers,andnotbyindividualoperators.

Inthecaseofoutsourcedlocationfunctions,agloballyuniqueECGIwillprobablybenecessarybecausetheremaynotbeadditionalinformationtobeabletoresolvetheECGIandlocation.


Annex B. Revision History

Version Date Description V1.0.0 2018-11-27 Release 1 of this Report

cbrsa-tr-0100 v1.0.0 identifier guidelines for shared hni

Documents