JAIN-SLEE

"A Service Logic Execution Environment (SLEE) is a high throughput, low latency event processing application environment". "JAIN SLEE is the Java open standard for a SLEE and is designed to allow implementations of the standard to meet the stringent requirements of communications network signaling applications".

The above two definitions explain the SLEE and JAIN SLEE. JAIN SLEE stands for Java API for Intelligent Network Service Logic Execution Environment. The basic purpose of it is, achieving scalability and availability in cluster systems.

JAIN SLEE is the only implementation which targets the portable communication. That is a "Write once, Run anywhere" situation. It allows telco applications to access resources and protocols of wide range of networks which are originating from JAIN SLEE environment. At the same time component based architecture helps in solving complex problems.

Fundamental concepts of Jain SLEE diverse into many areas including JAVA Community process, Service, Profile, Service building block, Event, Resources and Resource adaptors.

JAVA Community process

SLEE architecture implements in such a way that it supports component based model with defining the agreement between components and the container which holds them at run time. The management interface definition for administration of application environment and extension framework definition for adoption of new protocols.

Profiles

Profiles are used to store subscriber data and handle subscriber profiles. In service delivery platforms subscriber profiling would be easy with profiling concept of SLEE. Application would be capable of accessing subscriber profiles as part of their application logic.

Service Building Blocks (SBB)

Service building blocks are the software units which send and receive data in between them. Since, in SLEE components, they are viewed as services message parsing in between them is achieved through Service Building Blocks (SBBs).

Resources and Resource Adaptors

Resource adaptors provide the interface, for resources to connect to the container of the components, via JAIN SLEE architecture.

Since JAIN SLEE architecture supports many telco application developments by nature, it has many factors which influence the continuous improving performance, availability and the operational requirements demanded by the applications.

Importance of reliable software

Most of the time when it comes to system implementations, only hardware reliability is concerned. But it is a well known fact that the software reliability accounts to roughly 40% of the system downtimes. Because of that using reliable software will significantly enhance the application performance.

Next generation services

Next generation service offering such as Service portability, Network convergence and secure network access supportability affects the demand of the jain slee architecture which will eventually lead to continuous improvement.

Application development

For the developers who are willing to develop on top of the jain slee architecture, JAIN SLEE should provide a set of APIs to make the application developers' lives easy by making the application logic;

• Simple
• Functional through host process failures
• Executable independent of particular computing nodes
• Executable concurrently

The JAIN SLEE specification implications being favorable on application software architecture, software server would encourage application developers in producing telecom applications using the component based architecture with easy to use APIs.

Use a best breed of programming model

In application programming, developers using best practices and conceptual methods would also would have an effect on JAIN SLEE architecture as well. Object oriented programming model usage; modularized architecture would facilitate continuous performance improvement expected by the application on top of JAIN SLEE.

Standards based, Network independence and Portability some more factors which would affect the performance of the jain slee architecture in its implementations.

Different implementations of JAIN SLEE provide different availability guarantees, have different cluster architectures, provide different ACID semantics, and exhibit different latency and throughput performance. Following table is a comparison of well known "Event driven applications" and Enterprise applications".

Media Gateway Control Protocol (MGCP)

Media Gateway Control Protocol (MGCP) provides the signaling and call control protocol which is used to communicate between the Media Gateway Controller (MGC) and Media Gateway (MG). Basic purpose of the protocol depends on the direction of communication taking place. MGC instructs MG using MGCP about the media, events, signals to be played on endpoint. Creation of the connection, auditing the status of the endpoints and connections involved in the communication of media between networks is primary tasks of the protocol in MGC-->MG communication. At the same time, MG uses MGCP to report events to the call agent.

MGCP supports VoIP systems in which it provides an alternative method to call controlling. Since VoIP has following advantages compared to the traditional systems, even though replacement is not performed, slow adoption is performed in most of the implementations.

• Lower cost of network implementation
• Integration of voice and data applications
• New service features
• Reduced bandwidth
• Interoperation with traditional ss7 networks
• Seamless interworking in between the networks

In most of the networks, Signaling conversation and Media conversation is done separately as shown in the diagram below since it has many advantages.

• Media conversion closes to the traffic source and sink
• The call-handling functions is centralized
• MGC can control multiple gateways.
• New features can be added more quickly

Media Control Gateway Protocol should assist Media gateway in performing following activities in order to provide a quality service.

• The creation, modification and deletion of media streams
• Including the capability to negotiate the media formats
• The specification of the transformations applied to media streams
• Request the MG to report the occurrence of specified events within the media streams, and the corresponding actions
• Request the MG to apply tones or announcements
• The establishment of media streams according to certain QoS requirements
• Reporting QoS and billing/accounting statistics from an MG to an MGC
• The management of associations between an MG and an MGC
• In the case of failure of a primary MGC
• A flexible and scalable architecture in which an MGC can control different MGs
• Facilitate the independent upgrade of MGs and MGCs

There are 9 commands in MGCP to handle connections in which each and every command is acknowledged.

1. EPCF - EndpointConfiguration (coding characteristics)
2. RQNT - NotificationRequest (requested events)
3. NTFY - Notify (GW: detected events)
4. CRCX - CreateConnection
5. MDCX - ModifyConnection
6. DLCX - DeleteConnection
7. AUEP - AuditEndpoint
8. AUCX - AuditConnection
9. RSIP - RestartInProgress (GW : taken in/out of service)

Gateway Mobile Location Centre (GMLC)

Gateway Mobile Location Centre (GMLC) in short is a fuctinal entity which processes location of a Mobile Station (MS) upon a request from a proxy mobile location centre. It may contain various positioning methods in which it needs to calculate the position withing the requested accuracy level and the freshness.

The positioning methods implemented by the GMLC would be of two types; methods which calculate the position by the GMLC by itself and position calculation with the help of external entities. External entities would be Mobile Switching Centre (MSC), Home Location Register (HLR) or Visitor Location Register (VLR) which keeps the position information about the subscribers.

External entities which requires positioning informatin would access the GMLC by MLP requests with the accuracy level and the freshness. The accuracy level wouuld be defined by a radius and the freshness level will determine the duration in which the information are being captured about a particular mobile station.

Following diagram shows the flow of the informatin in capturing the position information.

GMLC would translate the operator specific Call Detail Record (CDR) information to location information in the primary positioning methods whereas in complex methods GMLC would perfome to the extent where it actually fetch new data from the operator network.

Following listed positioning methods are few among the famous efficient positining methods currently available in calculating the position

ATI

ATI method would access operator's HLR and get required information withing the specified freshness level. If data can not be found withing the required freshness level, GMLC would send a unnotified Short Message (SM) to the user and find the actual required data about the position of the handset.

PSI

In PSI method, GMLC would access the most recent VLR, where user has been doing transactions with the operator network, to find the position data. Informatin about the VLR to be accessed, is found by accessing HLR.

STK

Informatin reciding in the SMSC would be used in STK to find out the MS position information. Even though this method is less accurate than the previous methods, faster than accessing the entire Public Land Mobile Netowrk (PLMN).

CDR

CRR method will use the Call Detail Record (CDR), stored by the operator servers in calculating the position. This method is also efficient compared to the above method but with increased time in fetching data.

Using GMLC many innovative and attractive applications can be built which will eventually increase the operator revenue.

InfiniBand

InfiniBand is a new method of communication between I/O devices in the internet infrastructure. It's a switch fabric communication link which supports quality of service and fail overs providing a highly scalable solution for high performance computing with high availability.

Just like in other existing common communication channels, Fiber channel, PCI express, Serial ATA InfiniBand supports point to point communication, especially connnceting servers and storage disks. Diagram below shows how the InfiniBand comes in to play with a software implementation.

When comparing the features, InfiniBand have a higher bandwidth compared to other solutions. But Hyper transport channel has a higher max bandwidth allocation. As the transport medium, all three methods PCB, Copper and Fiber exist providing much more flexible solution at the same time providing much more signal length in both the fields, PCB and Copper. Another highlighting feature of InfiniBand is the maximum packet payload, 4KB which is very large relative to the values of the other channels.

InfiniBand Layers

The architecture of InfiniBand is divided into many layers which operates independant of one another. Mainly there are four divisions, Physical, Network, Transport and Upper layers.

Physical layer specifies the actual hardware, cables, backbones and tangible equipment which needs in InfiniBand communication.

Link layer is the heart of the architectur which handles three core tasks. Packet layout definition, point to point link operations and switching between local sub net.

Network layer handles routing paths between sub nets. It makes sure the packets are delivered from one subnet to another subnet.

Transport layer is placed in order to verify guranteed delivery. Partitioning, channel multiplexing and transport services are the services provided in transport layer.

InfiniBand Architecture

Modularization in software projects

Modularization is very important in software system designs since it provides a great flexibility to the extreme extent that no parts are relying upon any other parts. But still facilitating the communication among the modules in order to achieve the intended task.

Specially in consideration of an organization developing a large scale software solutions, in project management aspect, it allows breaking down the project in to smaller components which might have separate component boundaries and targets. No coordination among project teams would be necessary unless it is the integration phase. Well defined interfaces to pass data, communicate, will do the final task at the end, executing functions.

When it comes to the expansion, software being modularized provide flexibility and option to the developers and architects to add, edit, delete the modules with less effect to the other modules. Expansions would made a lot easier. It would be an addition of modules with it's new functions. No extra overhead would have to bear to integrate with the existing system.

There are many general advantages of achieving modularization

• Separation of concerns - Easier o limit the knowledge about the internals and the contents of classes on different levels or different tasks if they are organized into separate modules.
• Easier to maintain smaller components - In actual development it allows proper organized structure of folder structure, files naming etc providing less time consuming management and maintenance.
• Prevention of damages - A lot easier to manage and avoid potential damages to the software system. An error affecting one module would have least effect on other modules providing less damage to the end system.

There are some disadvantages as well in modularization

• Complexity - Especially in small projects, it increases the complexity making the design unnecessary complex with many overhead items
• Difficulty of understanding - Later referring of the codes would make it extremely difficult to understand if not proper naming conventions are used. Even though this factor depends on the programmer mostly, modularization could have an effect.