Technical Overview
The Network Interface Daemon (NID) is an existing application that has been utilized in replacing a similar piece of Ericssons hardware likened to the SOG. The NID can be deployed in single or multiple instances with a maximum of sixty-four (64) connections per NID instance and unlimited number of instances; relevant to SRP and ASAP instance configuration.
In addition the NID can be configured to translate NE, MML command response come codes to designate client statuses.
Originally designed as a Telnet peer Telnet messaging switching server the NID has evolved to enable it to be used as a base IP packet message server with an extensible plug-in message framework, linking two or more disparate systems.
The messaging framework has been extended with an application Request For Service Protocol (RFSP) data layer (CLI) “commands” to be transformed to external peer system format and returned in a similar transformed fashion.
- Enables translation between different Network Elements and hence providing the appropriate network provisioning between multiple manufacturers Network Switches utilising one manufacturers “MML” structure. ie Ericsson to Nokia MML commands.
- Offers the ability to interrogate the Network Element.
- Provides a means to provision to multiple Network Elements.
________________________________________________________________________
NETWORK INTERFACE DAEMON (NID) – Oracle Communications (ASAP SRP) Installation
Telco wants to replace existing Network Elements from Ericsson to Nokia. The Telco does not want to change the existing legacy applications
install an application that bridged the issue surrounding the use of the existing legacy system with interfacing to the new Nokia network element.
The following diagram illustrates the configuration of services within the NID SRP. The blue shaded boxes illustrate the extent of the SOF replacement components and toolkit delivered under the JEDIS framework. The diagram also illustrates how the components fit alongside the provisioning developments already deployed.
Note: That configuration described in this diagram using tables accessed by the SRP. No configuration is done within the NID.
ORACLE COMMUNICATIONS ASAP PRODUCT NID OVERVIEW.
A Work Order(WO) request will contain WO Parameters, Global Parameters, Services and Service Parameters. The WO request is converted into Common Service Description Layers(CSDLs). These CSDLs are then mapped to one or more Atomic Service Description Layers(ASDLs) and ASDL Parameters depending on CSDL parameter content. At the WO start date and time BASIC like State Tables are used to convert the ASDL’s into Network Element proprietary commands and manage the delivery of and the response to these commands. The results are interpreted and passed back to the client system.
ASAP system architecture is based on Sybase Open-Client & Open-Server technology. There are three major components to ASAP :
- Service Request Processor(SRP).
The SRP validates the RFS message and constructs the appropriate ASAP objects. i.e. WO’s, CSDLs, ASDLs. The SRP communicates with the upstream system in returning asynchronous notifications.
- Service Activation Request Processor(SARM).
The SARM processes ASAP WO’s in reception of WO’s from the SRP, management of ASDL’s sent to NEPs and various notification responses sent back to the SRP.
- Network Element Processor(NEP).
There can be any number of NEPs within ASAP. Each NEP is responsible for an allocated suite of Network Elements(NE) irrespective of NE platform e.g. HLR, MMS-C, VM, FNR, etc. An NEP manages sessions for each NE ; composing NE commands from ASDLs, sending the commands and receiving responses.
JEDIS release the NID and servant Plug-in applications on CD material. The current UNIX platforms supported are:
- HP HP/UX: 10.20,10.30, 11.0, 11i.
- SUN Solaris: 7&8.
- IBM AIX 4.3 Raven.
ORACLE Communications (ASAP) [current ] plug in supported is ASAP version 4.6.3 Oracle 9i on HP HP/UX 11i, 9000 PA-Risc 1.1 architecture.
For more information email nid@jedislimited.com