DAC Info Center Nokia DAC Applications User equipment Training | Offer & Order Order & delivery

Offer & Order Order & delivery DAC Internet Helpdesk Logout

Home Nokia Spectrum Access System (SAS)

Domain Proxy User Guide

Disclaimer

Terms and Definitions

Overview
Domain Proxy User Guide
Spectrum Access System Terms and Definitions
(SAS)
This chapter explains terms used in the Domain Proxy solution
Domain Proxy (DP)

Nokia DAC Domain Proxy Abbreviation Definition

Solution
CBRS Band Citizens Broadband Radio Service Band is a  MHz band of . GHz
Domain Proxy Features (- MHz) in the United States.

DP Application CBSD Citizens Broadband Radio Service Device

Deployment
A radio device that communicates in the CBRS band
CBSD to P-SAS
Connectivity for Multiple DA Timer Daily Activities Timer
CBSDs
Periodic coordination among SASs covers, for example, scheduled
Daily Activities (DA) Timer external database synchronization, full activity dump exchange, and
interference calculations for the protected entities. As a result, SASs
High Availability
calculate the allowable maximum EIRP for the CBSD to protect the
DP Application incumbents and decide whether to terminate or to authorize a
Undeployment CBSD to transmit. These coordination activities happen daily
among SASs.
Nokia DAC Domain Proxy
Installation and Deployment DC Data Center

DP Application Deployment and

DP Domain Proxy
Undeployment
CBRS band signalling traffic aggregator from CBSDs to SAS
Domain Proxy User Interface

DPA Dynamic Protection Area

Web Interface Login

EIRP Effective Isotropically Radiated Power

Additional Information
The maximum amount of power that could be radiated from an
antenna

ESC Environmental Sensing Capability

A sensor network that detects transmissions from Department of

Defense radar systems and transmits that information to the SAS

FCC Part  Federal Communications Commission

Part  – Citizens Broadband Radio Service

Subpart A – General Rules

Subpart B – Incumbent Protection

Subpart C – Priority Access

Subpart D – General Authorized Access

Subpart E – Technical Rules

Subpart F – Spectrum Access System

Subpart G – Environmental Sensing Capability

[Link]

Nokia DAC Nokia Digital Automation Cloud

NSC Nokia Spectrum Controller (also referred to as Nokia SAS)

PDAS Passive Distributed Antenna System

Passive DAS is a network of spatially separated antennas referred to

as Transmission Points (TPs) where the power of the Radio Unit (RU)
is split among antennas

SAS Spectrum Access System

A system that manages and authorizes the use of spectrum (-

MHz) for CBSDs in accordance with FCC regulation (part 
subpart F)

WInnForum Wireless Innovation Forum

Overview
New verticals such as Industrial Automation, Private Enterprise networks demand to have high-speed LTE
access capabilities that offer more reliable and superior QoS in comparison to Wi-Fi networks.

The 3.5 GHz Citizens Broadband Radio Service (CBRS) band spanning 3550MHz to 3700MHz, recently opened
in the USA under 47 CFR Part 96 rules, provides access to 150 MHz of a spectrum shared between several
incumbents (such as US Federal Entities, Earth Satellite Stations and legacy Wireless ISP operating under
Part90z) and commercial users to enhance the network capacity and performance.

The FCC mandated Part 96 rules created a three-tier spectrum access model for dynamic sharing consisting
following three tiers:

• Tier-1: Incumbents such as DoD ground-based radar systems, US Navy, Fixed Satellite Stations (FSS),
Wireless Broadband Services, etc. They are protected from users in the lower tiers.

• Tier-2: Priority Access Licensees (PALs). PAL licenses can be assigned up to 70 MHz. A PAL holder can get
authorized four separate channels (10 MHz each) up to 40 MHz. PAL users receive protection from GAA
users and must not cause any harmful interference to Tier-1 users.

• Tier-3: General Authorized Access (GAA). GAA users must not cause any harmful interference to upper-
tier users and do not receive any interference protection from other GAA, PAL, or Tier-1 users.

3.5 GHz CBRS band three-tier spectrum access model

The End-to-End architecture for the CBRS band standardized in the industry-standard body WInnForum’s
spectrum sharing committee (SSC) consists of the following building blocks:

• Spectrum Access System (SAS)

• Domain Proxy (DP)

• Environment Sensing Capability (ESC)

• Citizens Broadband Service Device (CBSDs) (that is 4G LTE eNBs, Access Points, or 5G gNBs)

Spectrum Access System (SAS)

Spectrum Access System (SAS) is the central entity in the CBRS architecture that handles the following
operations:

• Registering and authenticating the identity and location of the CBSDs.

• Determining interference to incumbents caused by the CBSDs within their neighbourhood.

• Computing the transmit power for the CBSD channel grants such that the aggregate interference to the
incumbent(s) does not exceed a prescribed threshold.

• Suggests CBSDs use new operational parameters in the form of maximum permissible transmission
power and/or permissible channel(s) or frequencies at their location.

CBSDs communicate with their managing SAS using the CBSD-SAS protocol, to inform their locations,
installation parameters, maximum transmit power, and the channel they wish to transmit on. They exchange
heartbeats with the SAS to obtain a grant and to maintain authorization to transmit. Heartbeat
acknowledgment from SAS indicates the CBSDs are authorized to transmit. If the CBSDs do not receive
such an acknowledgment within the specified time or they receive a negative (suspension, or termination)
acknowledgment they have to cease transmission.

Multiple SASs communicate with each other using SAS-SAS protocol to share data called Full Activity Dump
(FAD) files that contain information about the CBSDs and ESCs each of them manages. Periodic coordination
among SASs happens daily (using a daily activities timer). It is comprised of scheduled external (FCC and
WInnForum) database synchronization, full activity dump exchange, and interference calculations for the
protected entities.

SAS Solution Architecture

Nokia SAS solution supports a distributed SAS architecture where multiple SASs can be configured as
primary, secondary, or tertiary.

Primary SAS: Deployed in the Data Centers, it is the first point of contact for all CBRS devices to request
spectrum access. If a Domain Proxy (DP) is present, it will forward all CBRS requests under its control to
Primary-SAS. It is responsible to register new CBSDs, grant spectrum, suspend allocated grants, and de-
register CBSDs.

Secondary SAS: It acts as a backup SAS when primary is not reachable. It is deployed in the same or
geographically diverse secondary data center if present.

Local SAS (L-SAS): It is deployed at the EDGE. It becomes active when primary and (if configured) secondary
SAS is not reachable. If DP can not communicate with primary or secondary SAS, it forwards the heartbeats
to local SAS to keep the authorized CBSDs on the air until the next periodic activities among SASs start. A
CBSD can communicate with the local SAS only via DP.

Domain Proxy (DP)

Domain Proxy manages a group of CBSDs and communicates with one or more SASs on their behalf.

Domain Proxy serves as an aggregator of CBRS band signaling traffic from CBSDs to the SAS. From the SAS
perspective, DP is the entity controlling the CBSDs. DP hides or abstracts IP addressing of all or subset of or
more of the deployed CBSDs (eNBs) and relays all communications to/from the SAS to each of the deployed
CBSDs that are connected via DP.

Since the continuous transmission over the air for a given grant at the CBSD depends on the exchange of
heartbeat messages it is important not to break the communication with the SAS. DP supports the High
Availability feature by monitoring the connectivity to the primary and secondary SASs, and routing traffic
based on the availability of each SAS.

Domain Proxy provides managed access service to the CBSD owners via User Management and GUI, thus
allowing the CBSD owners to manage their CBSDs according to user-defined access control policies.

Nokia DAC Domain Proxy Solution

Nokia DAC Domain Proxy solution integrates Domain Proxy Application on DA edge for communication
between CBSDs and SASs. DP application is deployed on DA edge using Nokia DAC Application Framework.

The Nokia DAC Domain Proxy Solution offers the following main advantages:

• Augments the NDAC portfolio with the support of the 3.5GHz band and leverages the functionalities of
CBRS with DP.

• The Domain Proxy solution helps to aggregate the Traffic from CBSDs to the SAS. This helps in the
reduction of firewalls/NATs owing to the aggregation function. This also provides control of CBSDs to go
online or scheduled online etc.

• Reliability capabilities ensure

o Switch to Secondary SAS in case of failures of the Primary SAS

• Enables additional business cases via policy control features (such as time and criteria-based RAN
activation, pricing, and preferred channel allocation).

Domain Proxy Features

This chapter lists the key features supported by the NDAC NSC Domain Proxy Application.

CBSD to Primary-SAS Connectivity for Multiple

CBSDs
Multiple CBSDs can be connected to Primary-SAS/ Secondary-SAS via DP Application on DA edge. This helps
in the reduction of firewalls/NATs owing to the aggregation function.

High Availability
DP supports high availability feature that is in case of loss of connectivity from DP to Primary SAS and
Secondary SAS (if present).

Seamless failover is only available when DP is connected to Geo-Redundant Distributed Key Bridge – Nokia
Regional SAS instances that are configured as Primary and Secondary SAS instances. The feature is enabled
by setting the NOKIA_HIGH_AVAILABILITY flag to true in the configuration file. DP keeps track of remote
SAS’s communicability state by periodically pinging each SAS. When the communication to Primary-SAS is
lost (its state recorded as DOWN) an alarm is raised, and the CBSD-SAS messages are forwarded to the
Secondary-SAS if it is configured and its state is UP. When the communication to the Primary-SAS is
reestablished, the messages are forwarded back to the Primary-SAS.

Passive Distributed Antenna System (PDAS)

support
Passive DAS is a network of spatially separated antennas referred to as Transmission Points (TPs) where the
power of the Radio Unit (RU) is split among antennas. An RU can be connected to a single TP or multiple TPs.
Between the RU and each of the TPs, there are only passive elements (feeders, splitters, diplexers, etc.).

Passive DAS components do not require separate power, the RU is feeding the TPs via passive RF splitters.
All the TPs connected to the same antenna port could form a unique group called a passive DAS chain. All
the TPs of that group transmit on the same frequency and same bandwidth.

FCC Part 96 rules require each TP to be registered as a separate CBSD. During the registration, TPs use
WInnForum Release 2 Feature called “Enhanced CBSD Group Handling” to declare which Passive DAS group
they belong to. If one of the TPs belonging to a group is not authorized to transmit, then the RU feeding
that Passive DAS chain stops transmitting within 60 seconds which causes all the TPs belonging to the same
group to stop transmitting.

- NDAC Domain Proxy Passive DAS Solution

NDAC DP communicates with RU via the CBSD-SAS interface. RU sends registration requests for each
passive DAS group separately. Grouping is done based on the passive DAS chain association. In the below
Passive DAS example (below figure) there are two passive DAS groups. Group 1 has two TPs (TP_S1_1 and
TP_S2_1), and group 2 has one TP (TP1).

NDAC DP has the capability to support the CBSD-SAS protocol on behalf of each TP. The installation
parameters for each TP and the Group ID that an individual TP belongs to are entered by the CPI via DP
GUI.

Additionally, NDAC DP supports the WInnForum Release 2 “Enhanced CBSD Group Handling” feature. It
augments the registration requests for the TPs with:

“cbsdFeatureCapabilityList”:[“WF_ENH_GROUP_HANDLING”],
“groupingParam”:[{ “groupType” : ”PASSIVE_DAS”,
“groupId” : “<groupId>”}]
Where <groupId> = <FCC-ID>: ChainId
Where ChainId is the <common portion of the TPs SerialNumber>
TPs SerialNumber is the serialNumber of the RU:ChainId:<unique id of th

Passive DAS Example

- Passive DAS scenarios

- Passive DAS unsuccessful/successful registration

For the configuration given in the Passive DAS Example figure, RU sends two CBSD-SAS messages (one for
each group), DP replaces each message with one or more CBSD-SAS messages (an array of messages, one
for each TP). DP sends two registration requests for the first group with the associated CPI signed
installation parameters and the grouping parameters along with the Feature Capability List. SAS sends back
registration responses for each registration request with unique CbsdIDs corresponding to each TP if the
registration of a TP is successful.

The message flow for the first group is shown in the below figure. If any of the TPs registration is failed, DP
sends a single registration response with the received response code from SAS for the failed TP. When all
the TPs register successfully, DP sends a single registration response with success and a unique CbsdId to
the RU.

Registration Request message flow example with failure

- SAS does not support PASSIVE_DAS

If the response to the registration request with cbsdFeatureCapabilityList = WF_ENH_GROUP_HANDLING and

groupType = PASSIVE_DAS is supportedBySas = false, then the response with a failure is set to the RU.

Registration Response due to SAS does not support PASSIVE_DAS

- Handling of Spectrum Inquiry at the DP

DP checks Spectrum Inquiry responses from SAS to make sure the available channels are common for all TPs
in the group. If they are not, DP will send only the common channels to RU. If no common channel(s) are
found an empty array is sent (see below figure).

Spectrum Inquiry Request message flow example

- Grant Requests

Grant request includes the maxEirp for the RU. DP uses the eirpCapability (dbm/10MHz) that is entered by
the CPI via DP GUI, to calculate the maxEirp of each (dbm/1Mhz) TP when sending Grant Requests toward
SAS (see below figure). If any of the grants fails, a response with a failure is sent back to RU. DP will send a
relinquishment request for the successful grants in the group toward SAS. RU may try a different frequency
range for a new grant.
If all the grants are successful, a Grant Response with success and a grant id is sent back to RU.

Failed grant response and subsequent message flow

-- EirpCapability of a TP and the maxEirp in the grantRequest

CPI should supply eirpCapability of each TP. This can be calculated, measured, or obtained from the vendor.
eirpCapability of each TP can be calculated using the following formulas. NRU_TP(dB) represents the ratio of
the number of RU antenna ports, to the number of antennas connected to each TP in the dB domain.

The following illustrations are examples of how to calculate the TP eirpCapability for different configurations
and the value that should be used at the CBSD-R for maxEirp based on the limiting power (minimum of
each TP’s power). CPI must set the TP eirpCapability from the table when entering the information for the
CBSD from DP GUI.

- Handling Heartbeat Request failure

After the grant request succeeds, the RU sends a Heartbeat request. DP sends corresponding Heartbeat
requests for each TP using the grant Ids received from SAS for the prior grant requests. If any of the
heartbeat responses is suspended then all the TPs are suspended (see below figure).

Grant and Heartbeat Request message flow example with suspend

- Heartbeat Response after CPAS

If the maxEirp of the suspended TPs are reduced due to IAP calculations, DP will adjust the maxEirp that is
sent to the RU using the maximum delta (5 dbm reduction as opposed to the 3 dbm) to satisfy all the TPs’
allowed maximum eirps as shown in the below figure.

Suspended Heartbeat Response with terminate and allowed maxEirp

- CBSD Identifiers for sectors, DAS, and remote radio placements

FCC Part 96 rules require each TP to be registered as a separate CBSD with a unique identifier. Since FCC
certifies the radio equipment not antennas, the manufacturer’s serial number must be augmented to create
a unique identifier for each TP.

CPIs may register multiple CBSDs associated with the same radio equipment such as sectors of a single
physical site.

Some deployments of radio equipment may divide the transmission into sectors, for example, the three
sectors or cells of a single physical site. Each sector of such a deployment that is registered with the same
FCC ID and Manufacturer’s serial number can be assigned a unique Sector ID by the installer.

Some deployments may further support one or more TPs mapped to a unique Sector ID of equipment that
has a unique FCC ID and Manufacturer’s serial number.
For the purpose of unique CBSD identification, four deployment scenarios have been distinguished based
on the number of sectors and the number of TPs per sector. [WInnF-TR-5001] (RU’s serial number: serial1)

Category 1: A single-sector RU with a single TP per sector: One CBSD is registered in this case using the TP
location, the FCC-ID, and Manufacturers' Serial Number of the RU. (here, TP’s serial number: serial1:1)

Single sector single TP

Category 2: A multi-sector RU with a single TP per sector: In this case, every sector of the RU may have a
unique transmission location. Each sector is registered as a single CBSD using the FCC ID, and the
Manufacturers Serial Number of the RU is combined with an additional Sector ID to uniquely identify each
sector. Specifically, Sector ID can be appended to the Manufacturers Serial Number with a delimiter
character ‘:’ preceding the Sector ID (for example, serial1:s1:1, serial1:s2:1).

Multi-sector single TP

Category 3: A single-sector RU deployed as a Passive DAS with multiple TPs. Each TP is registered as a single
CBSD using the FCC ID, and the Manufacturers Serial Number of the RU is combined with an additional TP ID
to uniquely identify each TP (for example, serial1:tp1, serial1:tp2).

Single-sector multiple TPs (Dual-port single sector antennas for 2x2 MIMO deployments)

Category 4: Multi-Sectored RU supporting multiple TPs in some or all of its sectors. Each TP of each sector
is registered as a single CBSD using the FCC ID and Manufacturer Serial Number of the RU combined with
additional Sector ID and TP IDs to uniquely identify each TP of each sector (for example, serial1:s1:tp1,
serial1:s2:tp1)

Multiple-sector multiple TPs (Dual sector dual-port antennas for 2x2 MIMO deployments)

- DP GUI

All the TPs regardless of their category (A or B) must be installed by a Certified Professional Installer (CPI).
CPI may rely on the expertise of a third-party accredited DAS network planner/installer to determine the
eirpCapability of each TP. CPI will also determine whether a deployment environment is indoor or outdoor,
category A or B.
The serial number that is chosen for the TP and the Group ID that the TP belongs to must be configured
using the DP GUI. A sample form is shown below in the figure.

Sample form for CPI to enter the installation parameters of a TP

After entering the data, CPI generates the signature using its private key and password; if it is successful,
validates the signature, and save it. The encoded data is sent in the Registration Request of the TP.

Users can add the Multiple CBSDs by following the below steps.

. Download the template file version 1.0.0 provided by DP.

. Fill the DP_CPI_upload_template.xlsx and save it.

. Upload the updated file.

Users can view the PDAS Groups on a separate tab View PDAS Groups.

View PDAS Groups

- NDAC Domain Proxy Passive DAS Solution Using Airscale

In the below figure, NDAC Domain Proxy (DP) communicates with Airscale via the CBSD-SAS interface and
presents DAS TPs as individual CBSDs to the SAS on behalf of each TP. Airscale registers with the FCCID and
Manufacturer’s serial number, asks for grant(s), and may adjust the transmit power based on the responses
from the DP.
DP replicates the CBRS requests coming from Airscale into a number of requests towards SAS, one per TP.

DP associates the Registration Request from RU with the TPs configured by the CPI on the DP based on
the PDAS group they all belong to. Using the installation parameters, eirp capability of each TP, and the
grouping parameters, it sends Registration Request(s) with CPI signed installation parameters and Passive
DAS group indicator for the Feature Capability List. If SAS responds with success for all the TPs, the DP
sends back a success response to Airscale.

DP uses the CPI-entered eirpCapability for the maxEirps in Grant requests to SAS

It merges the responses coming from the SAS into a single response toward Airscale.

The SpectrumInquiry response is the intersection of the channels available to all the TPs. If there is no
common channel found among all the TPs then an empty array is sent to the Airscale.

When the response for the heartbeat request after a CPAS, results in a power reduction, the maxEirp
assigned to each CBSDs is adjusted based on the maximum reduction so that each TP’s maxEirp does
not exceed their assigned power by the SAS.

NDAC DP Passive DAS Solution Architecture for Airscale BBU and AZQC CBSD

In the below figure, a sample indoor plan is shown. The plan ensures each antenna operates within the
indoor EIRP limit.

AZQC’s Cat-B radio power is divided among all the antennas, splitters, and cable runs such that each
antenna operates within Cat-A power limits.

Each antenna is registered as a separate Cat-A CBSD within a passive DAS group at the SAS.

DP performs the mapping from Airscale AZQC to passive DAS CBSDs, including message replication for
the same.

Sample indoor plan; AZQC with passive DAS

Nokia DAC Domain Proxy Installation and

Deployment
Contact Nokia DAC Operations personnel for Hardware details, installation, and deployment of Nokia DAC
Domain Proxy solution.

DP Application Deployment and Undeployment

Customers can Deploy DP Application on DA edge using Nokia DAC Customer UI after Nokia DAC operations
personnel enables DP license and completes the pre-requisites for DP Application.

Also, customers can Undeploy DP Application using Nokia DAC Customer UI.

Domain Proxy User Interface

This section describes the procedures for the various functions of the Nokia DAC Domain Proxy Web
Interface.

Web Interface Login

DP web interface login details (URL, default Username, and Password) would be shared with customers by
Nokia DAC operations personnel. Users can log in to the DP web interface on DA edge using these
credentials.

The first-time user starts the Web Interface, following screen appears.

Users must enter the default Username and Password upon the first login.

Result: The system prompts you to change the password.

A new password must meet the following criteria:

• min 8 characters long.

• atleast 1 special character.

• atleast 1 letter.

• atleast 1 number.

During subsequent logins, user must enter the new password.

In case, the user does not remember the password, click Forgot Password on the login screen. A pop-up
window appears with the following text to update the password → Please contact your Administrator for
further assistance.

An administrator can delete and recreate this user account.

Home Page Overview

The DP web interface home page consists of the following sections:

Session Timer

My Work

Summary

Account Tools

Session Timer
DP web interface supports specific session time per user which is 30 minutes by default. Users can extend
this session once by 30 minutes by clicking the ‘clock sign’ next to the timer.

Note This would extend the session by 30 mins from the time when the clock sign is clicked.

Summary
Upon clicking the Summary section following screen appears. This has 3 tabs i.e. ‘Summary’, ‘View CBSDs’
and ‘Policy Management’.

‘Summary’ tab displays the number of registered CBSDs in real-time and a graphical view of a number of
"Grant or suspended" and "Authorized" grants.

After the CBSD is registered (successful exchange of Registration Request message with the SAS), it
requests a grant to transmit for specific operating parameters, that is maximum EIRP and Channel. A CBSD
may request multiple grants. Each Grant is identified by a unique Grant Identifier. Once issued, Grants
operation parameters are never changed. If new operating parameters are required (that is maximum EIRP is
changed or the channel is not available due to an incumbent), SAS terminates the Grant and a new grant
must be obtained.
A Grant may be in different states. After a successful Grant Request, it is in a GRANTED state. In order to
transmit, a successful Heartbeat Request/Response must be exchanged between the CBSD and the SAS,
and the Grant state becomes AUTHORIZED. A CBSD performs periodic Heartbeat exchanges with the SAS to
stay in the AUTHORIZED state. A Heartbeat Request failure (grant suspension) causes grant to move to
GRANTED/SUSPENDED state where CBSD stops the transmission until the next successful Heartbeat
exchange happens.
The below screenshots shows the number of "Grant or suspended" and "Authorized" grants.

View Grants
Information related to the registered CBSDs with the grant details can be viewed on this tab.

CPI Management
CPI user can modify the value of already installed CBSDs. In CPI management, user can see and edit the
install CBSDs.

Policy Management
The administrator can define/modify the policies that can be applied to CBSDs. This gives control to
customers to start, stop, block the CBSDs. This gives control to customers to start, stop, block the CBSDs.
CBSD can be activated, blocked, and waived for the specified time based on the policy applied.

Procedure to add a policy to a CBSD

A policy can be added in the following two categories:

. Active/Block

. Waiver

Step 1: Select CBSD to which policy has to be applied.

1. Add Policy: Active/Block

Step 2: Select “Apply Policy” tab in View Grants page.

Enter the following details:

Policy name

CBSD state as either active or blocked

Start date

Start Time

End time

Time Zone

Repetition

Step 3: Click to add policy.

2. Add Policy: Waiver

Step 2: Select “Apply Policy” tab in View Grants page.

Enter the following details:

Policy name

CBSD state as Waiver

Waiver ID

Start date

End date

Start Time

End time

Time Zone

Start Frequency

End Frequency

Step 3: Click to add policy.

Procedure to Edit a policy to a CBSD

A policy can be edited in the following two categories:

. Active/Block

. Waiver

Step 1: Select CBSD to which policy has to be edited.

Step 2: A new window is opened, enter the mandatory fields and click update policy.

Edit Policy for Active or Blocked state:

Edit Policy for Waiver state:

Account Tools - DP User Administration

Upon clicking the ‘Account Tools’ section following screen appears.

This section describes how to create, delete and modify the user details from the above ‘Account
Management' screen.

User Roles
Each user role specifies one or more functions that allow a user to perform tasks for those functions. The
DP provides a default admin user account and a number of default roles. The admin user has the
Administrator role, which allows the admin to perform all of the functions in the DP web interface, including
the creation and management of additional users.

The following user roles are supported:

• DP Administrator
• CBSD Owner
• CPI Tech

Maximum Number of Users:

• Maximum of 6 Admin (including default Admin user) and

• Maximum of 10 CBSD owners.

DP administrators can perform the following operations:

• Add new users

• Delete users

• Modify users

• Change password

Add new user

DP admin can add the following three types of users:

• DP Administrator
• CBSD Owner
• CPI Tech

The following procedure is executed by the Admin to add a new user.

STEP 1: In the Account Management, click ADD NEW USER.

Result: Register New User window opens and prompts you to enter the following details.

• Email*

• Username*

• User type*

• Password*

• Confirm Password*

STEP 2: Click Register.

Result: User gets the message Successfully Registered.

Note: To add a CPI Tech user, the DP Admin must add the registered CPI ID as shown below.

Delete user
The following procedure can be executed by the Admin to delete an existing user.

STEP 1: In the Account Management, click Delete Users.

Result: Select one user window that opens, prompts you to select the user you want to delete from the
drop-down list. Select the user that you want to delete.

STEP 2: Click Delete.

Result: A confirmation window to delete the user pops up.

STEP 3: Click YES.

Result: User gets the message Deleted Successfully.

Suspend user
The following procedure can be executed by the Admin to suspend an existing user.

STEP 1: In the Account Management, click Suspend Users.

Result: Select one user window opens prompts you to select the user you want to suspend from the drop-
down list. Select the user that you want to suspend.

STEP 2: Click Suspend.

Result: Confirmation windows to suspend the user pops up.

STEP 3: Click YES.

Result: User gets the message Suspended Successfully.

Change Password
The following procedure can be executed by the Admin to Change Password for an existing user.

STEP 1: In the Account Management, click Change Password.

Result: Change Password window opens prompts you to enter the details.

• Username*

• Current Password*

• New Password*

• Re-enter Password*

STEP 2: Click Change Password.

Result: Password updated success.

Additional Information
Refer “Nokia DAC Solution Description” document for additional information about Nokia DAC.

[Link]

Contact Nokia DAC Operations personnel for additional details and troubleshooting tips for the Nokia DAC
Domain Proxy solution.