AIS-CI and RAI-CI Generation and Detection

The device can transmit and detect the RAI-CI and AIS-CI codes in T1 mode. These
codes are compatible with and do not interfere with the standard RAI (Yellow) and
AIS (Blue) alarms. These codes are defined in ANSI T1.403.


The AIS-CI code (alarm indication signal-customer installation) is the same for both
ESF and D4 operation. Setting the TAIS-CI bit in the TR.T1CCR1 register and the
TBL bit in the TR.T1TCR1 register causes the device to transmit the AIS-CI code.
The RAIS-CI status bit in the TR.SR4 register indicates the reception of an AIS-CI signal.

The RAI-CI (remote alarm indication-customer installation) code for T1 ESF operation
is a special form of the ESF Yellow Alarm (an unscheduled message). Setting the RAIS
-CI bit in the TR.T1CCR1 register causes the device to transmit the RAI-CI code. The
RAI-CI code causes a standard Yellow Alarm to be detected by the receiver. When
the host processor detects a Yellow Alarm, it can then test the alarm for the RAI-CI
state by checking the BOC detector for the RAI-CI flag. That flag is a 011111 code in
the 6-bit BOC message.

The RAI-CI code for T1 D4 operation is a 10001011 flag in all 24 time slots. To
transmit the RAI-CI code the host sets all 24 channels to idle with a 10001011 idle
code. Since this code meets the requirements for a standard T1 D4 Yellow Alarm, the
host can use the receive channel monitor function to detect the 100001011 code
whenever a standard Yellow Alarm is detected.

Extensible Access Control Markup Language

XACML is an XML specification for expressing fine-grained information access
policies in XML documents or any other electronic resource.

At configuration time, XACML expresses and communicates the rules and policies
that an access-control mechanism uses to derive an access decision for a set of
subjects and attributes. By comparison, at run time SAML formulates assertions
about subjects, their attributes, and their access rights. For digital rights
management or workflow processing use cases, an application or medium can
transmit XACML rules together with the content to which access is being regulated.
If necessary, mechanisms outside XACML must but be used to enforce the
integrity of access rules and confidentiality of content.

The XACML specification defines ways to encode rules, bundle rules to policies,
and define selection and combination algorithms in cases where multiple rules and
policies apply.

Access control lists in XACML are 4-tuples—subject, target object, permitted
action, provision. The subject can include user IDs, groups, or role
names. The target object allows granularity down to a single XML document
element. The permitted action primitive can be either read, write, create, or delete.
This represents a major XACML limitation because it does not accommodate
domain-specific permission types. A provision is an action that must execute
upon a rule’s activation (for both deny and grant rules). Such actions may include
initiating log-in, requesting additional credentials, and sending an alert. The
XACML specification defines a language for formulating such provisions.