Interoperability Testing (IOT)
Over the last few years I have performed many Multi-Vendor projects that have required Interoperability testing, or IOT testing as it is also know as. In a Multi-Vendor environment it doesn't matter how thorough the project solution is planned when it comes to connecting Multi-Vendor products together there are, in 9 cases out of ten, "Interoperability" problems. Here are a few thoughts from four different technology areas that I have experienced;
Radio Access Network IOT
With the strength of OEMs such as China`s Huawei increasing each year it is common for the most loyal of customers to introduce other vendors products into their networks. When this happens they perform Multi-Vendor Integration projects and part of the project is; IOT testing.
With RAN products such as the 3G WCDMA Radio Network Controllers (RNC) the IOT testing is concerned with the handover of traffic from one vendors RNC to the other. It is usual for both OEMs to have a project team and in several cases although we are integrating towards each other the customer will instruct us that we cannot communicate (speak) to each other! Understanding the frustrations of the engineers a good Project Manager will accidentally bump into the other team in the canteen.
Access Network IOT
Unlike legacy PSTN switches which commonly have command line interfaces the Access network nodes tend to have more of a Graphical User Interface. Within these GUI (gooey) interfaces there are frequently selectable node types that the user can click on or select so that the node will auto configure the interface to the switch type selected. For example; the Alcatel Litespan Access node has a pre-configured S12 interface. This makes life easy for the O&M or Integration engineer. Point it towards an MV environment however and you could end up learning how to use a protocol analyser.
PSTN Network IOT
PSTN interoperability testing tests whether the V5 protocol can function correctly with the intended target node(s) interface environment, i.e, the target node(s) interface hardware, software or firmware.
Usually there are less than a dozen individual parameters that will need setting (matching) on either side of a V5.x protocol link. The most well known being the Variant ID, Link ID, etc (ref. wiki).
Where specified, pre-agreed test cases require that combinations of the intended target nodes environment is configured and available to the test team. The test case results are normally measured or compared with the existing interface(s) as part of the acceptance criteria.
Multi Vendor Repair Capability & IOT
Planning a "new repair capability" development project from scratch is one thing. It always seems to work on paper. Realising a "working" new repair capability from scratch is another thing all together.
In all cases the solution needs to achieve a level of working operation to enable the repair technicians to repair down to component level.
Interoperability can be a tough phase during the development.
This is a capture log of me using a Protocol Analyzer to watch the Ericsson DIAmuX connecting to the Local Exchange across an aggregate link using the V5.2 protocol.
You can see the Control protocol from the DIAmuX Access Network (AN) initiating the setup of the V5 link towards the Local Exchange (LE).
V5 is an older protocol and can be a bit of a nightmare when it doesn't want to work. If you have any problems drop me a line.
There is a very good V5 high level article on Wikipedia here and a good high level reference to CC Signalling here; Common Channel Signaling (CCS)
The Digital Local Exchange (DLE) is the same as an Ericsson AXE10 Local Host Exchange and like the Ericsson Local Host the DLE connects to the concentrators (CONCs) via a 2Mbit PCM link running V5 protocols. The Ericsson equivalent of a CONC is a Remote Subscriber Stage (RSS).
It is in the CONC that the line cards are placed.
In order to route calls to different DLEs or DMSUs all traffic is quantanised (i.e analogue to digital converted speech placed in to Time Slots and built into Time Frames) which are placed on to the 2Mbit 30 channel PCM COAX highways and sent out from the Concentrator Units towards the Time Switches. In Ericsson AXE10 world this can be written as ETB to ETC via 2Mbit COAX using V5.2 and on to TSM/SPM.
Thereafter it is routed using the B-number analysis and placed onto the correct Routing Case depending on the destination of the call.
The above switch is one of the most robust switches I have ever experienced as it has been moved at least 6 times during its (to date) 30 years of service.
This is a Fastlink roadside cabinet that has been setup in the test plant for testing of telephony, data and broadband services. The services are based on the Optical Network Unit (ONU) which operates as a compact unit for subscriber access, protocol, routing and transport and also the Optical Line Termination (OLT) which in turn acts as a central access point to the local exchange, the data networks and the ATM/IP networks.
In this configuration above we are using V5C concentration signaling towards the Access Network (AN) side and via a CMXII-LS shelf using V5.2 signaling towards the Local Exchange (LE) side.
The Fastlink Subscriber Line shelf (UMX2S AMXC) supports on the exchange side both the open V5.2 or V5.1 protocols and an additional FastLink internal concentrating V5C protocol when used together with
the cross connect multiplexer (called CMXII-LS.) This way concentration rates of up to 4:1 are possible within the ONU itself.