Tài liệu Dịch vụ mạng thế hệ kế tiếp P3 pptx

The basic aim of IN is to decouple the service logic from the control of the switch fabric, a stage further than could be achieved by the use of a stored program controller, and to creat

Intelligent Networks

The Intelligent Network (IN) standards are divided into the Telcordia standardisation called Advanced Intelligent Networks (AIN) and the International Telecommunications Union telecommunications (ITU-T)

IN standards capability sets The Telcordia standards are used mainly

in North America, whilst the ITU-T standards are relevant in pretty much the rest of the world Other work has taken place notably by a group known as TINA-C, the Telecommunications Information Network-ing Architecture Consortium, lookNetwork-ing at the longer term architectures for distributed intelligence in telecommunications networks

The early implementations of IN were based on a database performing number translation of non-geographic numbers such as the US 800 services, and these basic services continue today These services were built on a network enabled by signalling system number 7 (SS#7) and

IN continues to build on SS#7 More recently IN implementations cover

a more extensive set of services from time of day routing plans, find-me follow-me services, pre-paid mobile services (wireless intelligent networks), calling card services, to advanced network-based call centre agent skill routing

The basic aim of IN is to decouple the service logic from the control of the switch fabric, a stage further than could be achieved by the use of a stored program controller, and to create a platform that allows new services to be constructed from smaller building blocks This later capabil-ity is expressed in Q.1201 as ‘‘integrated service creation and implemen-tation by means of the modularised reusable network functions’’ The principle business aim of IN is the removal of a dependency on switch manufacturers for the provision of new services In order to achieve this

Neill Wilkinson Copyright q 2002 John Wiley & Sons, Ltd ISBNs: 0-471-48667-1 (Hardback); 0-470-84603-8 (Electronic)

aim, the use of an SS#7 infrastructure is a prerequisite Section 1.2 discusses the protocol stack of SS#7 and mentions the IN protocol – Intel-ligent Network Application Part (INAP) It is INAP that facilitates the decoupling of service logic from switching functions

The development of IN service capabilities within the European Tele-communications Standards Institute (ETSI) is specified in releases called Capability Sets (CS), the first (obviously) being CS1 The ETSI work repre-sents a clarification of the ITU-T standards and tries to add real-world experience to the theoretical standardisation effort Each capability also creates a new release of the Intelligent Network Application Protocol (INAP) to support the remote invocation of services in an intelligent network, by providing the mapping from functional to physical entities (see later in this chapter) Further work has taken the IN standardisation

to CS4, however, the actual number of implementations of anything other than CS1 are low1 In Europe a number of IN implementations are based

on what has become known as ETSI core INAP – CS1, specified in ETS 300 374-1

The time for IN is arguably gone, with new computing platforms and open standards for service execution environments just around the corner (see Chapter 10) The author also believes the telecommunications indus-try has become restless and disappointed with IN implementations and standards progress The new software-based platforms called soft-switches (see Section 10.3) being developed and session initiation protocol (SIP) servers (see Section 5.6) will replace the IN infrastructure; Ovum predicts this will happen by as early as 2003

This sounds like a bleak future for IN, so why cover intelligent network technology here? The truth is that a lot of network operators have imple-mented IN successfully (and at considerable sunk cost), and are now sitting on a cash cow that will continue to deliver revenue beyond 2003 This revenue will be ploughed back into the development of new services

in one of two ways, either to continue the evolution of their incumbent IN platforms to bridge circuit switched and packet switch worlds (in Chapter 10.4 the future of IN services is discussed and the work of a group in the Internet Engineering Task Force that looks to provide the ability for IN to interact with Internet-based services and vice versa), or to purchase soft-switches and SIP proxy servers (see Chapter 5) Also the concepts for a distributed service network that are introduced in the IN standardisation are extremely useful in understanding the way new services in a call server architecture might be developed and delivered (we’ll explore this further in the next section on services and explore how IN as it is

1

It could be argued that CS3 implementations exist, because CS3 brings IN inline with the next generation of mobile networks under the standardisation for the Unified Mobile Telecommunications System standardisation (UMTS) activity and describes some of the

IN services for mobile use

now could evolve to have a place in the next-generation networks, see Section 10.4)

The IN is decomposed into a number of layers, each of these layers are called planes, which form the IN conceptual model – INCM (ITU-T, Q.1201) This conceptual model is a framework for the construction of

an IN architecture, not the architecture itself, an important distinction The four planes are: service plane (Q.1202), global function plane (Q.1203), distributed function (Q.1204) plane and physical plane (Q.1205) (Figure 3.1)

I’ll only examine the planes at a high level If you would like to explore

IN further than is presented here, I suggest [FAYN] as a good place to start, followed by [IAKO] for how IN-based broadband networks have been specified (the suspicion of the author is that the broadband IN stan-dardisation effort will/has been overtaken by the adoption of application frameworks and protocols such as media gateway control protocol (MGCP) and SIP2)

The service plane is where the services reside The global function plane describes a model network of functionality from a global or network-wide perspective The distributed function plane describes, in a supplier inde-pendent way, the functions of the components that constitute an IN The physical plane is where real network hardware resides and it embodies the functions described in the distributed function plane, and arguably is the easiest plane to understand

The service plane recommendation (Q.1202) is a short document, four pages to be exact It describes how a service can be categorised and describes the undesirable feature of service interaction This is where the capabilities provided by one service if used in conjunction with another service produces an undesirable result For example call waiting,

a service designed to inform a caller that the person they’re trying to reach

is already engaged in a call, whilst also informing the person already on a call that someone else is trying to reach them This service generally allows the called party to toggle between their existing call and the new caller to establish alternating conversations between the two Addition-ally the service also offers the ability to connect all three parties together for a conference call Clearly this service requires the called party to be able to control the calls they have both in progress and trying to reach them, it would be incompatible to try to implement this call waiting service at the same time as implementing a call diversion on busy service,

2

See Chapters 12 and 5 respectively for an explanation of application frameworks, MGCP and SIP

since call diversion on busy would try to divert the second caller away before any conversation could take place Clearly, these two services can’t coexist

The global function plane describes the proper location for the modu-larity aspects of services construction The concept of a Service Indepen-dent Building Block (SIB) is introduced It describes Points of Initiation (POI), Points of Return (POR) and Basic Call Processing The relationship

of these to each other (in the form of the Global Service Logic (GSL)) is shown in Figure 3.2

SIBs are standard (i.e specified in the standards for each capability set) reusable functional components that services can be constructed from Each SIB describes a single complete atomic capability that is independent

of any physical component of the network A service is created by effec-tively chaining SIBs together, these chains of SIBs create what is referred

to as the GSL The Basic Call Process (BCP) is in essence a special SIB that allows the passing of call related data from the other network elements, and in this way provides both a mechanism for handing over control of a call to the IN service and provides basic call processing functionality to the service logic The BCP SIB defines entry and exit points to the call processing so that other SIBs can be invoked These interaction points are

Figure 3.1 IN conceptual model

the POI, where call processing is handed over to the service (specifically the GSL), and POR where the results of the service execution hands back control to the call processing software

The Distributed Function Plane (DFP) describes the functional elements/entities of:

† Service Management Function (SMF), the provisioning, billing and fault monitoring functions

† Service Management Access Function (SMAF), interface between administrators and the SMF

† Service Creation Environment Function (SCEF), the offline function for the creation of service logic from the SIBs

† Service Control Function (SCF) controls the execution of services and contains a function known as the Service Logic Execution Environ-ment (SLEE), where the combined SIBs in the form of Service Logic Programs (SLPs) execute

† Call Control Function (CCF), basic call connection and release, essen-tially the inheritance from the stored program controller basic call control capability

† Service Switching Function (SSF), the interface between the CCF and SCF manages the triggers in the CCF for interaction with the IN service INAP is the protocol used to connect the SSF and SCF This

is in essence an instance of the special BCP SIB described above

† Special Resource Function (SRF), provides such things as digit recog-nisers, recorded announcements and voice recognition capabilities for the interaction between callers and service logic

† Call Control Agent Function (CCAF), essentially the signalling between the user and the network for example Integrated Services Digital Network (ISDN) Q.931

Figure 3.2 Relationship of SIBs, POI and POR to BCP

The physical plane is populated with: Service Control Points (SCP, the physical embodiment of the SCF), Service Creation Environment (SCE, the physical embodiment of the SCEF), Service Switch Points (SSP, the physical embodiment of the SSF), Signalling Transfer Point (STP), Specia-lised Resource Platforms (SRP, also called Intelligent Peripherals (IPs), the physical embodiment of the SRF) and finally the Service Management Platform (SMP, the physical embodiment of the SMF and in some instances the SMAF too) Their relationship is shown in Figure 3.3 The SSP is the stored program controller that we discussed earlier, in the case of IN the code for the call model (called the Basic Call State Model (BCSM), essentially the CCF) finite state machine has been modified (with the SSF) to include break points that allow the call routing to be paused for originating calls and terminating calls called the o_BCSM and t_BCSM The break points in the SPC BCSM are called Detection Points (DPs) Each one of these triggers is separately settable either by a maintenance action

or via a message from the SCP logic, to allow the call progress to be interrupted as various stages in the call processing (called Points In Call (PIC)) The PIC essentially map on to the POI and POR described in the BCP SIB defined in the global function plane

The CS1 specifications do not allow for interaction between the origi-nating and termiorigi-nating call models and describes what are called type A services, i.e single point of control (only one SCF can interact with the

Figure 3.3 IN physical architecture

BCSM at a time) and single ended (SCF can only interact with an isolated half of a call, originating or terminating, but not both)

The STPs are responsible for routing SS#7 messages and whilst are present in the IN architecture, are actually part of the SS#7 architecture

as discussed in Chapter 1 STPs were discussed in relation to a feature known as Global Title Translation (GTT) With reference to Figure 3.3, we will explain the importance of GTT If the service code, say 0800 is used as

a Global Title (GT) (i.e the reference used to find an instance of a service that can be invoked) then the STP in the IN architecture can choose to route the INAP messages via Signalling Connection Control Part (SCCP) GTT to either of the SCPs in the diagram This means that load sharing can take place and also if an SCP fails, then the failure would be transparent to the switch

That’s a whistle-stop tour of IN that hopefully gives a flavour of the work and thought that has gone into defining the way services can be created in a manufacturer independent way The IN Conceptual Model (INCM) and the work of the TINA-C group (not described here) have gone a long way in assisting in the thinking process for Next-Generation Network (NGN) services and in some networks the current IN infrastruc-ture may actually evolve to be the NGN service function or call agent capability (see Section 5.6 for a description of a call agent) In Part 2, Chapter 11, the IN’s integration with call centres will be explored as a current service that can be improved upon by the use of NGN services