Cellular MDA and ports

Up to two valid SIMs must be procured before configuring the cellular MDA or cellular ports. The SIMs must be inserted into the proper SIM slots before the node is powered up. SIMs cannot be installed when the node is powered on. To run the Automatic Discovery Protocol (ADP-Hm) on the node, a SIM must be inserted into slot 1; otherwise, ADP-Hm will not function. For more information about ADP-Hm, see "Basic system configuration" in the 7705 SAR-Hm and SAR-Hmc Main Configuration Guide.

For information about dual SIM operation, see Dual SIM deployment.

A down-recovery timer can be set so that if the cellular MDA fails to establish cellular service or if BGP cannot be established on any interface configured in the system, the node will reboot. The down-recovery-interval is configured at the cellular MDA level and is not specific to a particular SIM. The timer can be set when there is a single SIM or two SIMs installed in the node.

The operator can specify the criteria that will cause the node to reboot by configuring the down-recovery-criteria command. The down-recovery-criteria can be set to port or bgp. When set to port, all cellular ports configured on the system are monitored during the down-recovery interval. When set to bgp, all BGP sessions configured on the node are monitored during the down-recovery interval. Both options can be specified concurrently, and the node will use either the cellular port state or BGP session state to declare the operational state of the node as down.

When set, the down-recovery-interval specifies the length of time that the configured down-recovery-criteria are monitored from the moment when either the ports or the BGP sessions are declared operationally down. If the interval is exceeded without any port or BGP sessions going operationally up, the node reboots so that the preferred SIM can try to connect to a cellular network again. As soon as any port or BGP sessions is operationally up, the down-recovery timer stops.

The down-recovery-interval is measured in minutes, with a range of 1 to 240 minutes. Sixty seconds before the timer expires, the node will issue a log event stating that the node will reboot in 60 seconds if the down-recovery condition (based on the configured criteria) is not resolved. This 60-second warning interval can be used for further debugging and diagnostics before the node resets.

The node supports dual SIM deployment for users who require a redundancy option using two wireless carriers.

With dual SIM deployment, two SIMs are installed in the node, one from each carrier. Only one SIM is active at a time to establish a cellular service WAN connection. The operator choses which SIM is primary and which is secondary or manually selects which SIM to keep active.

Configurable criteria give the operator some control over when it is appropriate for the system to perform a SIM switchover. For example, the BGP operational state associated with the cellular port can be used as a criterion for determining when a SIM switchover should occur. If the BGP operational state is down for a specified interval, a SIM switchover occurs. See Criteria for automatic failover for more information.

Dual SIM operation shows dual SIM operation on a 7705 SAR-Hm.

For information about IP/MPLS services when dual SIM functionality is enabled, see the 7705 SAR-Hm and SAR-Hmc Main Configuration Guide.

The node provides a single PDN connection for each cellular port. A cellular port must have an associated PDN router interface in order to allow routed traffic and services over the PDN connection and over the cellular network. For more information about the PDN router interface, see "PDN router interfaces" in the 7705 SAR-Hm and SAR-Hmc Main Configuration Guide.

The node supports the configuration of an access point name (APN) as part of a PDN profile in order to establish the PDN connection. In many cases, the default PDN profile is sufficient to establish a connection. For example, often the only configuration that is necessary to establish a connection is to enable the port using the config>port port-id no shutdown command. However, some carriers may require the user to configure a specific APN before allowing a connection to be established. In those cases, the user must configure a PDN profile and configure the cellular port to use that PDN profile. See PDN profile for more information.

When acting as a CBSD, the 7705 SAR-Hmc must complete TLS authentication to communicate with the SAS/DP server. The 7705 SAR-Hmc supports TLS 1.2. For more information about TLS, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide.

A secure TLS connection to a SAS/DP requires X.509 certificates configured on the CBSD. The operator must acquire an ICM account to request and download device-level CBSD certificates. For each CBSD that requires a certificate, the operator can upload the FCC ID and serial number to the ICM portal, submit the request for the certificates, and download the certificate .pem files.

In addition, the operator must download the following CA certificate files from the ICM portal:

• the INSTA root CA certificate (included with the device-level CBSD certificate)
• the INSTA manufacturer CA for the CBSD (included with the device-level CBSD certificate)
• the INSTA root CA’s CRL file URL
• the INSTA manufacturer CA’s CRL file URL
• the SAS/DP root CA certificate (contact the SAS/DP provider for this certificate)
• the SAS/DP intermediary certificate (contact the SAS/DP provider for this certificate)
• the SAS/DP root CA’s CRL file URL (contact the SAS/DP provider for this CRL file URL)
• the SAS/DP intermediary CA’s CRL file URL (contact the SAS/DP provider for this CRL file URL)

The operator must FTP the CA certificate files listed above into the temporary directory on the CBSD and then use the admin>certificate>import CLI command to import each CA certificate.

The following examples show the admin>certificate>import command for each CA certificate:

*A:SARHmc# admin certificate import type cert format pem input 
cf3:/newcerts/WInnForum_RSA_Root_CA.pem output WInnForum_RSA_Root_CA.cer

*A:SARHmc# admin certificate import type cert format pem input 
cf3:/newcerts/WInnForum_RSA_CBSD_Mfr_CA.pem output WInnForum_RSA_CBSD_Mfr_CA.cer

*A:SARHmc# admin certificate import type cert format pem input
cf3:/newcerts/RSA_Root_CA_CA0001.pem output RSA_Root_CA_CA0001.cer

*A:SARHmc# admin certificate import type cert format pem input
cf3:/newcerts/RSA_SAS_Provider_CA_0002.pem output RSA_SAS_Provider_CA_0002.cer

The operator must FTP each CRL file for each CA certificate into the temporary directory on the CBSD and then import them using the admin>certificate>import CLI command for each file.

The following examples show the admin>certificate>import command for each CRL file:

*A:SARHmc# admin certificate import type crl input 
cf3:/newcerts/InstaCBRSRootCAv2.crl output InstaCBRSRootCAv2.crl format der

*A:SARHmc# admin certificate import type crl input 
cf3:/newcerts/InstaCBSDMfrCA0004.crl output InstaCBSDMfrCA0004.crl format der

*A:SARHmc# admin certificate import type crl input 
cf3:/newcerts/InstaCBRSRootCA_SAS.crl output InstaCBRSRootCA_SAS.crl format der

*A:SARHmc# admin certificate import type crl input 
cf3:/newcerts/InstaSASCA0002.der_CA_0002.crl output InstaSASCA0002.crl format der

The CA periodically updates the CRL file, which must also be updated on the CBSD. The CBSD can be configured to automatically update the CRL for a CA with the auto-crl-update CLI command under the ca-profile context.

The following example shows a sample auto-crl-update configuration:

config
	system
        file-transmission-profile "http" create 
            redirection 5
            router "management"
        exit
        security
            pki
                ca-profile "GTS_CA_1C3" create
                    cert-file "GTS_CA_1C3.cert"
                    crl-file "GTS_CA_1C3.crl"
                    auto-crl-update create
                        crl-urls
                            url-entry 1 create
                                file-transmission-profile "http"
                                url "http://crls.pki.goog/gts1c3/QOvJ0N1sT2A.crl"
                            exit
                        exit
                        no shutdown
                    exit
                    no shutdown
                exit
            exit
        exit

For each CA certificate, a CA profile must be configured using the config>system>security>pki>ca-profile command. The CA certificate and CRL file are assigned to the CA profile with the cert-file and crl-file commands. The example below shows a sample CA profile configuration. The operator can use the show>certificate>profile CLI command to confirm that each ca-profile is operationally up.

The device-level CBSD certificate and key file must be imported into the CBSD. The operator must download the PKSC12 certificate file from the ICM portal, FTP the file into the temporary directory on the CBSD and then use the admin>certificate>import CLI command to import the certificate file and key file.

The following example shows the admin>certificate>import command for the CBSD certificate and key file:

*A:SARHmc# admin certificate import type cert input cf3:/newcerts/CBSD_NS213062783.p12 output 
CBSD_NS213062783.cer format pkcs12 password PASSWORD

*A:SARHmc# admin certificate import type key input cf3:/newcerts/ CBSD_NS213062783.p12 output 
CBSD_NS213062783.key format pkcs12 password PASSWORD

The configuration of CBSD authorization on the cellular interface includes a TLS client profile configuration. The TLS client profile uses the imported CBSD certificate and key file, the CA certificate profiles, and the SAS/DP root trust anchor to authenticate a TLS session between the CBSD and SAS/DP. The TLS client profile is configured using the config>system>security>tls>client-tls- profile CLI command on each CBSD.

The following example shows a sample configuration of CA profiles and the TLS client profile:

config
    system
        security
            pki
                ca-profile "WInnForumRootCA" create
                    cert-file "WInnForum_RSA_Root_CA.cer.cer"
                    crl-file "WInnForum_RSA_Root_CA.crl"
                    no shutdown
                exit
                ca-profile "WInnForumCBSDMfrCA" create
                    cert-file "WInnForum_RSA_CBSD_Mfr_CA.cer"
                    crl-file "WInnForum_RSA_CBSD_Mfr_CA.crl"
                    no shutdown
                exit
                ca-profile "RSARootCA0001" create
                    cert-file "RSA_Root_CA0001.cer"
                    crl-file "InstaCBRSRootCA.crl"
                    no shutdown
                exit
                ca-profile "RSASASProviderCA0002" create
                    cert-file "RSA_SAS_Provider_CA_0002.cer"
                    crl-file "InstaSASCA0002.crl"
                    no shutdown
                exit
            tls
                cert-profile "cbsd_cert_profile" create
                    entry 1 create
                        cert "CBSD_NS213062783.cer"
                        key " CBSD_NS213062783.key"
                        send-chain
                            ca-profile "WInnForumCBSDMfrCA"
                            ca-profile "WInnForumRootCA"
                        exit
                    exit
                    no shutdown
                exit
                trust-anchor-profile "sas_trust_anchor_profile" create
                    trust-anchor "RSA_Root_CA0001"
                exit
                client-cipher-list "sas_client_cipher_list" create
                    cipher 1 name tls-rsa-with-aes128-gcm-sha256
                    cipher 2 name tls-rsa-with-aes256-gcm-sha384
                exit
                client-tls-profile "sas_client_tls_profile" create
                    cert-profile "cbsd_cert_profile"
                    cipher-list "sas_client_cipher_list"
                    trust-anchor-profile "sas_trust_anchor_profile"
                    no shutdown
                exit

The main components of the TLS configuration for the TLS client profile include:

• the cert-profile of the CBSD that specifies the certificate file, key file, and CA certificate chain
• the trust-anchor-profile that specifies the SAS/DP root CA trust anchor to the TLS session
• the client-cipher-list supported by the CBSD (the CBSD supports the following two ciphers, tls-rsa-with-aes128-gcm-sha256, and tls-rsa-with-aes256-gcm-sha384)
• the client-tls-profile details, which include the cert-profile, cipher-list and trust-anchor-profile

See the 7450 ESS, 7750 SR, 7950 XRS, and VSR Classic CLI Command Reference Guide for more information about the CLI commands discussed above.

For mutual authentication, the CBSD authenticates the SAS/DP server and the SAS/DP server authenticates the CBSD. During the TLS message exchange, the CBSD authenticates the SAS server using the procedures in RFC 2818, HTTP Over TLS. Server certificate validation is performed according to RFC 5280, Internet X.509 PKI Certificate and Certificate Revocation List (CRL) Profile. If the CBSD cannot authenticate the server, the TLS connection establishment procedure is aborted. The CBSD reattempts the TLS connection every 60 s.

The CBSD sends its client certificate to the SAS server, where the SAS performs the client authentication based on RFC 5280. If the SAS server fails to authenticate the CBSD, the TLS connection is terminated.

If a TLS connection is established with the SAS/DP, the registration process begins.

When router interface Network Group Encryption (NGE) is configured on a PDN router interface that is enabled for CBSD authorization, an exception filter must be configured to ensure that SAS control packets are permitted. The filter must allow the following:

• outbound and inbound clear text traffic to and from the primary SAS. The server IP address must be known.

• outbound and inbound clear text traffic to and from the secondary SAS server, if configured. The server IP address must be known.

• outbound and inbound clear text DNS queries and responses using the DNS server information learned in the PCO. The IP address returned from the DNS query must be known and statically configured for the primary and secondary SAS server addresses.

• outbound and inbound clear text SSH sessions

In order for the SAS to discover the 7705 SAR-Hmc as a CBSD, the SAS administrator provides the CBSD operator with a URL to the primary SAS server and, optionally, a URL to a secondary SAS server. The URL is used in the sas-server-primary and sas-server-secondary CLI commands.

When the CBSD attaches to the wireless network, the DNS server IP address is used to resolve the SAS server URL. The CBSD attempts to establish an HTTPS session with the primary SAS server and, optionally, the secondary SAS server. If the attempt to establish a session with the primary SAS server fails, the node attempts a session with the secondary server if it is configured. If that attempt fails, the 7705 SAR-Hmc will wait 60 s before reattempting an HTTPS session with the primary server.

After the CBSD is discovered by the SAS server and authentication is complete, the CBSD creates a secure session with the SAS and begins the registration procedure by sending a registration request.

The registration request includes the following parameters:

• configured CBSD user ID

• FCC ID:

  • for the 7705 SAR-Hmc North America variant (3HE12472AAAB): AS57705SARHMC-1

  • for the 7705 SAR-Hmc North America variant 2 (3HE12473AAAA): AS57705SARHMC-2B

  For both nodes, the FCC ID is used for CBRS B48 CBSD categories A and B.

• CBSD serial number

• configured CBSD category A or B

  The CBSD category supplied in the registration request and the category configured in the CLI must match.

• air interface — set to E-UTRA, as defined in the Wireless Innovation Forum Signaling Protocols and Procedures for Citizens Broadband Radio Service (CBRS): WInnForum Recognized CBRS Air Interfaces and Measurements, Document WINNF-17-SSC-0002

If the CBSD had any existing grants with the SAS before sending the registration request, they are deleted.

The SAS sends the CBSD a registration response that contains the following parameters:

• CBSD ID

• response — an indication of whether the registration request is approved

The CBSD ID is stored by the CBSD and used for all subsequent procedures with the SAS.

If the registration request fails for any reason, the CBSD retries the request every 60 s.

Before it can initiate the grant procedure, the CBSD must be registered with the SAS.

The CBSD determines the operational parameters that will be used in the grant request and initiates the grant procedure by sending a grant request.

When the grant request is successful and the CBSD receives a valid heartbeat response, the CBSD is authorized to transmit using the parameters specified in the request.

The 7705 SAR-Hmc supports the following parameters in a grant request:

• CBSD ID

• operational parameters:

  • maximum EIRP — the CBSD maximum EIRP, determined by calculating the sum of the antenna-gain and max-tx-power values configured in the CLI. This total must be within the range expected by the SAS for the CBSD category.

  • operational frequency range — this information is retrieved from the cellular interface when the CBSD attaches to the network

The SAS sends the CBSD a grant response that contains the following parameters:

• CBSD ID

• grant ID

• grant expire time

• heartbeat interval

• response — an indication of whether the grant request is approved

If the grant ID is included in the grant response, the grant request succeeded. As soon as the grant request succeeds, the CBSD uses the heartbeat interval parameter to start the heartbeat procedure. The heartbeat is needed for the grant to be authorized.

The CBSD uses the grant expire time parameter to determine when the grant expires. The 7705 SAR-Hmc stores this value and sets a timer equal to the expiry time minus 1 h minus the current time. When this timer expires, there is 1 h left before the grant expires and the 7705 SAR-Hmc sets the grantRenew flag to attempt a grant renewal. If the grant is not renewed, the grant request process is restarted.

If the SAS determines an error in the grant request and does not include a grant ID parameter in its response, the grant request failed. The 7705 SAR-Hmc retries the request every 60 s.

Upon receiving a successful grant response, the CBSD sends a heartbeat request at every heartbeat interval to indicate to the SAS server that the spectrum is required.

The 7705 SAR-Hmc supports the following parameters in the heartbeat request:

• CBSD ID

• grant ID

• grant renew — the node sets this parameter to TRUE when 1 h remains before either the grant timer expires or the heartbeat interval is longer than 30 min and two heartbeat requests can be sent before the grant timer expires. If either of these conditions cannot be met, this parameter is not included in the heartbeat request.

• operation state — the node sets this parameter to GRANTED when a heartbeat response has not yet been received for the grant and to AUTHORIZED when a successful heartbeat response has been received.

The SAS sends a heartbeat response that contains the following parameters:

• CBSD ID

• grant ID

• transmit expire time — the time that the CBSD must stop transmitting plus 60 s

• grant expire time — the time the grant expires. When included in the grant response, the 7705 SAR-Hmc uses this value as the new grant expire time.

• heartbeat interval — the maximum interval, in seconds, between two consecutive heartbeat requests. This value is used to set the heartbeat timer. If the value is changed by the SAS, the node uses the new value for this parameter.

• response — an indication of whether the heartbeat request is approved

If the transmit timer expires before the CBSD receives a heartbeat response, the CBSD stops transmitting for the grant within 60 s of the timer expiry.

A heartbeat request is sent at every heartbeat interval. The heartbeat interval timer is set when the CBSD receives a grant response or a heartbeat response that includes a defined heartbeat interval. If no heartbeat interval is defined, the CBSD uses the default value of 30 s.

The 7705 SAR-Hmc disables the dynamic filter on the PDN router interface when the heartbeat response is the first successful response it receives after sending a grant request. Disabling the filter allows the router interface to operate normally and for any enabled SR OS features to operate.

If the heartbeat response includes a suspended grant message, the CBSD is no longer authorized to use the spectrum. The 7705 SAR-Hmc re-enables the dynamic filter on the PDN router interface to disable SR OS features and allow only SAS control messages over the interface.

The CBSD sends a request to relinquish a grant when:

• the heartbeat response includes a terminated grant message

• the heartbeat response includes an unsync-op-param message

• changes in any radio parameters are detected

• the CBSD holds a grant and the user issues the cbsd-authorization shutdown command

When a relinquish request is sent, the 7705 SAR-Hmc re-enables the dynamic filter on the PDN router interface to stop the SR OS traffic and allow only SAS control messages over the interface.

After receiving a relinquishment response or after 30 s, whichever comes first, the CBSD initiates a new grant request to reauthorize with the SAS.

The 7705 SAR-Hmc deregisters from the SAS if one of the following occurs:

• the cbsd-authorization shutdown command is issued in the CLI

• the SAS returns a DEREGISTER code in its response

• the CBSD goes operationally down

• the band changes to one that is not a CBRS band

• the channel changes

• the maximum power value changes

If the CBSD deregisters from the SAS for any reason other than issuing the shutdown command in the CLI, the CBSD restarts the authentication procedure as described in Authentication procedure for TLS connection to the SAS/DP.

Some deployments require the 7705 SAR-Hmc to use CBRS B48 and another band in order to operate. For example, in P-LTE networks, CBRS B48 can be used with B8 (privately owned and controlled) using a single SIM or Verizon may offer carrier LTE services using CBRS B48 with a single Verizon SIM.

The 7705 SAR-Hmc checks the radio parameters periodically, and if the band is not CBRS B48, it will relinquish the grant because it is no longer using the CBRS B48 spectrum. However, the node will attempt to maintain the registration with the SAS even while on the non-CBRS band.

If the 7705 SAR-Hmc reconnects to CBRS B48 and it is still registered with the SAS, it will enable the dynamic filter on the PDN router interface to stop SR OS traffic. The 7705 SAR-Hmc will initiate a grant request to re-establish the grant and its ability to use the CBRS B48 band. If the node was deregistered while on the other band, it will attempt the CBSD authorization process from the beginning, starting with the registration procedure.