Share

Xenon Hardware Architecture

Many of the Classic switching architectures now support the V5.2 protocol. But these architectures were not originally designed with V5.2 in mind, the implementations are not efficient in terms of hardware and software resource requirements. Xenon is a switch that will be designed to serve as a LE.

Xenon takes advantage of the advances in semiconductor technology by combining many distinct components on a traditional switch, into a single card. This leads to cost reduction in hardware as well as software. Another objective for the Xenon hardware designers is to reduce the number of card types. Lesser card types make the switch easy to manufacture and maintain. Reduced software complexity is the additional benefit of having fewer card types. 

Another major objective of Xenon is to keep the hardware cost low. To achieve this all the Xenon cards will be designed around the PC motherboard, using standard PC components, as much as possible. Using the PC hardware platform has the additional benefit of allowing use of standard tools for software development.

Switching Architecture

 

space switch-time switch connectivity

The figure shown above illustrates the basic architecture of the Xenon switch. The core logic of the switch is implemented in just two cards:

  • Central Access and Switching Processor (CAS)
  • Xenon Extended Network Processor (XEN)

The XEN processor directly interfaces with the telecommunication network via a network of standard 2Mbps digital trunks. The XEN processor connects to the CAS processors with a 64Mbps coaxial links. The 64Mbps streams implements a 1024 time-slot PCM highway towards the space switch (also called the CAS highway). The XEN processor contains a time-switch, enabling a time-slot on any of the digital trunks to be switched to any timeslot on either 1024 time-slot CAS highways.

The CAS processor houses the space switch which permits any time-slot on the CAS highway from one XEN processor to be switched to the corresponding slot on the CAS highway to another XEN processor. It may be noted here that the space switch cannot switch in time, so time-slot X on one CAS highway can be switched only to time-slot X on another CAS highway.

Each XEN processor is connected to the two CAS processors via distinct CAS highways. With this connectivity, the two CAS processors provide two parallel space-switching networks. Each network is capable of switch 1024 slots. Thus a total switching capability of 2048 slots is available to serve 1024 possible calls in the system. This additional capacity is required to implement a almost non blocking switching fabric. This is explained in detail in the next section.

Non Blocking Switching

The CAS cards implement a space switch, if only one such switching element was present, the system would have supported switching for 1024 slots. This appears to be adequate for switching maximum simultaneous calls that a XEN can support. But in reality this configuration is blocking, as we do not have complete freedom in selecting any time slot on the CAS highway.

Consider the example of switching a call between a XEN-0 and XEN-1 processor. The call can be connected only if the same time slot on the CAS highway is free in both the switches (as the space switch cannot switch in time). If both the XEN processors are carrying 1023 calls each (i.e. one less than capacity), this call from XEN-0 to XEN-1 may not connect because the free time-slot on XEN-0 may not match the XEN-1 free time-slot. This condition is said to be blocking, because the called subscriber is available, but the system cannot find a free path to the subscriber.

To implement a completely non switching fabric, the system should be able to connect a call in the worst case, i.e. 1023 calls on XEN-0 have been connected to subscribers on XEN processors other than XEN-1 and the 1023 calls on XEN-1 have been connected to subscribers on XEN processors other than XEN-0. In a true worst-case scenario, the slot selection is such that no common slots have been used to establish these calls. If a call is made in this worst case scenario has to be connect, the system would need 1023 (XEN-0 to rest) + 1023 (XEN-1 to rest) + 1 (for this call). Thus a total of 1023*2+1 slots are required towards the space switch. Generally speaking, the slot requirement for a N subscriber XEN processor is (N-1) + (N-1) +1, i.e. 2N-1 slot space switch is required. Xenon implements a 2048 slot space switch using the two CAS cards.

Messaging Architecture

In this section we will cover the message communication architecture used in the Xenon Switching System. The messaging architecture is fairly straightforward. Each XEN and CAS processor supports a 10/100 Mbps Ethernet port. These links are routed directly to a LAN switch. The biggest advantage of using a LAN switch is that it almost eliminates message losses due to collisions on the LAN, thus giving a fairly high message throughput. Also, the delays in the system are also reduced.

messaging architecture

The messaging architecture has been kept fairly simple. This will help in quick routing of messages between different processors in the switch. A simple architecture also simplifies the design of software to handle message routing. Using an off-the-shelf LAN switch reduces development cost. It also reduces the overall cost of the system because a custom developed message router would cost more. Development cost in the project is further lowered by use of standard IP protocol. Working with a well-established and stable protocol will help stabilize the system faster.

OMC

In addition to all the familiar components you can see here, the system has to support an Operations and Maintenance Center (OMC). The OMC also connects directly to the LAN switch. The OMC is implemented as a high-end dual processor running Windows 2000. The OMC is directly connected to the LAN switch. The OMC will have the following functions:

  • Broadcast of the software release from the OMC to the CAS and XEN processors
  • Alarms and Reports about the health of the switch
  • Operations and Maintenance commands
  • Subscriber and Equipment provisioning