Signaling System No.7 Protocol Architecture And Sevices part 43

Chia sẻ: Dasdsadqwe Dsadasdsadsa | Ngày: | Loại File: PDF | Số trang:13

Thêm vào BST

Báo xấu

37
lượt xem 3
download

Signaling System No.7 Protocol Architecture And Sevices part 43

Mô tả tài liệu

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Additional IN Service Examples Two additional services are presented here to reinforce how IN operates in a real network context. The LNP service represents a government mandated service need

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Signaling System No.7 Protocol Architecture And Sevices part 43

Additional IN Service Examples Two additional services are presented here to reinforce how IN operates in a real network context. The LNP service represents a government mandated service need, while the PVN demonstrates a solution to a common business need. Both services can be implemented using any of the IN versions discussed in this chapter. Local Number Portability (LNP) The North American Local Number Portability Act of 1996 relies on IN technology to deliver number portability for subscriber numbers. Prior to LNP, blocks of phone numbers were associated to specific exchanges. Routing of interexchange calls was based on the NPA-NXX portion of the called number. The NPA identifies a particular geographic region, and the NXX identifies the particular exchange. The long-term goal of LNP is to associate the phone number with individual subscribers, effectively removing the network node association and allowing subscribers to keep their numbers. This means that, as users migrate throughout the network, a particular SSP will eventually handle many different NPA-NXX combinations instead of just one or two. Number Portability is being rolled out in phases that are designated by three different types of portability: • Service Provider Portability • Service Portability • Location Portability Service Provider Portability is the first phase and is currently being implemented. It allows subscribers to choose a different service provider but remain within their local region. More specifically, they must remain within their present rate center, which is generally defined as a local geographic area of billing, such as a Local Access Transport Area (LATA). Service Portability gives the subscriber the ability to change types of service while keeping their same phone number. For example, a basic telephone service subscriber can switch to ISDN service without changing numbers. Location Portability allows subscribers to change geographical regions and take their phone numbers with them. At this point, phone numbers will not necessarily represent the geographical area in which they reside. Because LNP is removing the association between subscriber numbers and
network nodes, some means of associating a particular user with a point of network access is required. Each office now has a Location Routing Number (LRN) assigned to it that uses the same numbering scheme that existed before the introduction of LNP. The LRN uses the NPA-NXX-XXXX format to allow compatibility with the existing routing method that is used in the network. In essence, subscribers retain their numbers, while the exchange retains its primary identification number and creates a mapping between the two. This brings us to the point of IN's role in providing the LNP service. When the first subscriber within an NPA-NXX changes service providers, the entire NPA-NXX is considered "ported," which means that this particular NPA-NXX combination has become a portable number and no longer represents a specific exchange. Every call to that NPA-NXX must now determine the LRN of the number that is being called. Because all subscribers with that NPA-NXX no longer necessarily reside in the same exchange, the exchange must be determined before the call can be completed. This immediately creates two needs that are readily satisfied using IN: • Trigger an LRN request for NPA-NXX codes that have been ported • Maintain the relationship between subscriber number and LRN The SSP maintains a list of ported NPA-NXX codes. When the call is being translated, the called number's NPA-NXX can be compared with the list of ported codes to determine whether a query should be sent to the SCP. NOTE At the point in time at which most numbers are ported within each network spanning a numbering plan, it will no longer be necessary to determine whether a query should be performed. Queries will then be performed for all calls. This decision point is generally governed by individual service providers. Until that point, each SSP must differentiate between the codes that have and have not been ported. The SCP maintains the relationship of subscriber numbers to LRNs. It maps the Called Party Number sent in the query to an LRN and returns the LRN to the SSP. The SSP uses the LRN as the Called Party Number to route the call to the correct exchange and includes the real Called Party Number in the GAP parameter of the ISUP IAM so that the terminating switch can deliver the call to the subscriber. If the SCP determines that the number has not been ported, it simply returns the
original Called Party Number, which the SSP uses to route the call. Figure 11-20 shows an example of a subscriber changing service providers, resulting in their DN being ported from SSP B to SSP A. SSP B is considered the donor switch because it is donating a number that once resided at that exchange. SSP A is considered the recipient switch because it is receiving a number that it did not previously have. When the subscriber at SSP C dials the 392-4000 number, SSP C performs a number translation and determines that 919-392 is open to portability. Because the number is portable and does not reside on the local switch, an IN query is sent to the SCP. The SCP returns the LRN of SSP A, which is now the home for the dialed number. The call is then routed from SSP C to SSP A using ISUP signaling. The original dialed number is placed in the ISUP GAP, and the LRN is placed in the Called Party Number (CDPN) field. For more information about how ISUP is used with LNP, refer to Chapter 8, "ISDN User Part (ISUP)." Figure 11-20. Local Number Portability Service [View full size image] The LNP service can be supported using IN/1, IN CS-1, or IN CS-2 call models. Using IN/1, the query sent to the SCP contains a "Provide Instructions/Start" component, while the response from the SCP contains a "Connection Control/Connect" component. In an AIN network, it is triggered at the SSP by the PODP (AIN 0.1) or SDS trigger at the Info_Analyzed DP. The AIN response from the SCP is an Analyze_Route message. Because the query could be performed at different points in the network, the LNP standards identify the N-1 network as the node for sending the query. This is the last network to handle the call before the terminating local network. Private Virtual Network (PVN) The PVN is a service that uses public network facilities to create a private network. An organization with geographically separate locations can share an abbreviated dialing plan using IN to translate the dialed numbers into network-routable addresses. From the user's perspective, it appears that they are on a private network. To determine the call's routing address, the SSP that serves the originating access queries an SCP using the called number, ANI, and other information. An IN response is returned to the SSP with the new routing address
and call processing is resumed. Figure 11-21 shows a company with three locations that are virtually networked over the PSTN. The company employees can use an abbreviated dialing plan to access other locations in the same manner as on-campus calls. The number the employee dials must be translated into an address that the PSTN can route. This happens transparently to the originator of the call, using the IN network to retrieve routing information. The call can then be completed across the PSTN to the San Jose location. Figure 11-21. Private Virtual Network Service [View full size image] The PVN service can be supported using IN/1, IN CS-1, or IN CS-2 protocols. Using IN/1, the query sent to the SCP contains a "Provide Instructions/Start" component, while the response from the SCP contains a "Connection Control/Connect" component. In an AIN network, the PODP (AIN 0.1) triggers it at the SSP or the SDS triggers it at the Info_Analyzed DP. The AIN response from the SCP is an Analyze_Route message. < Day Day Up >
< Day Day Up >
Intelligent Network Application Protocol (INAP) The ITU defines the INAP protocol, which is based on the same ITU capability sets and CS call models that are discussed in previous sections of this chapter. The ITU Q.12xx recommendation series defines this protocol. INAP is the protocol that is used for IN communication throughout Europe and in most places outside of North America. The ETSI 300 374 1-6 series of specifications refines the ITU documents for the use of INAP in the European region. Application processes use the INAP protocol to perform remote operations between network nodes, such as an SSP and SCP, in the same general manner as the AIN examples that were previously discussed. INAP uses ITU TCAP to deliver these remote operations, which are encapsulated within the TCAP component sublayer to peer application processes at the remote node. Like the various versions of AIN, INAP defines its own set of remote operations and parameters that are used at the component sublayer. While they provide similar functionality to those used by North American AIN, they are distinct in their definition and encoding. Table 11-2 shows the operation codes that are used between the SSF/CCF and SCF FEs for CS1 and CS2. These operations are invoked between the SSP and SCP network nodes. Recall from the earlier discussions about FEs that the SSF/CCF FEs reside within the SSP, while the SCF FE resides within the SCP (or adjunct processor). Table 11-2. SSF/SCF Operations for CS1 and CS2 SSF/CCF—SCF Operation CS1 CS2 ActivateServiceFiltering ActivityTest ApplyCharging ApplyChargingReport AssistRequestInstructions CallGap CallInformationReport
CallInformationRequest Cancel CollectInformation Connect ConnectToResource Continue ContinueWithArgument CreateCallSegmentAssociation DisconnectForwardConnection DisconnectForwardConnectionWithArgument DisconnectLeg EntityReleased EstablishTemporaryConnection EventNotificationCharging EventReportBCSM FurnishChargingInformation InitialDP InitiateCallAttempt ManageTriggerData
MergeCallSegments MoveCallSegments MoveLeg ReleaseCall ReportUTSI RequestNotificationChargingEvent RequestReportBCSMEvent RequestReportUTSI ResetTimer SendChargingInformation SendSTUI ServiceFilteringResponse SplitLeg Table 11-3 shows the operation codes that are used between the SCF and SRF FEs for CS1 and CS2. These operations are invoked between the SCP (or adjunct processor) and Intelligent Peripheral (IP) nodes, which hosts the SCF and SRF FEs, respectively. Note that these tables do not include all INAP operations. Additional operations for communication, such as SCF-SCF, exist; however, this section focuses only on those operations that are directly related to services at an SSP. Table 11-3. SCF—SRF Operations for CS1 and CS2
SCF—SRF Operation CS1 CS2 PlayAnnouncement PromptAndCollectUserInformation PromptAndReceiveMessage ScriptClose ScriptEvent ScriptInformation ScriptRun SpecializedResourceReport Basic Toll-Free Example Using INAP This example uses a few of the INAP operations from Table 11-2 to define a simple example to illustrate how INAP is used. Figure 11-22 shows the message flow for a basic toll-free service using INAP. The toll-free application at the SSP determines that communication with the SCP is necessary to retrieve information for the toll-free service. Figure 11-22. INAP Toll-Free Message Flow A TCAP Begin message is sent to the SCP with an InitialDP operation code. The InitialDP operation indicates that a TDP has been encountered at the SSP, thereby requiring instructions from the SCP to complete the call. The only mandatory parameter for the InitialDP operation is the ServiceKey parameter, which selects the appropriate SLP or application for processing the operation at the SCP. The
InitialDP component can include several optional parameters. Using our example in Figure 11-21, the CalledPartyNumber parameter is included to indicate the toll- free number. In this case, the CalledPartyNumber parameter is required to obtain a routable destination number from the SCP. The SCP translates the toll-free number to a routable number that is to be returned to the SSP. The SCP responds with a TCAP End message that contains Apply Charging and Connect operation codes. The Apply Charging operation indicates that charging should be applied for the call and might contain a PartyToCharge parameter to indicate whether charges should be applied to the calling or called party. In the case of a toll-free or free phone call, charges are applied to the called party. The Connect operation contains the DestinationRoutingAddress parameter to specify the routable destination number for connecting the call. Depending on regulatory policies and agreements, information such as the Carrier parameter can be returned in the Connect component to specify a particular IXC-providing service for the freephone number. This example is a very simple version of a toll-free service. It could also include connections to an IP, along with many other variations in the message flow and parameters. The example has been kept simple to provide an understanding of what a simple INAP exchange looks like for a service and to avoid the varying nuances of how the service might be deployed. As the figure shows, INAP provides operations that are similar to those of AIN at the component sublayer. However, the operations have been tailored to the needs of the European region, thus adhering to the ETSI specifications. Service Creation Environment (SCE) SCE provides a set of tools for creating the service logic that is executed at the SCP. This allows SPs to build and deploy their own services. Several SCEs are available, each differing in features and capabilities; however, they all share a common purpose of generating program code that can be executed by the SCP. Many SCEs provide a Graphical User Interface that allows software components to be joined together at a high level using visual tools to represent a service. Further modifications and customizations are applied by setting the properties that are associated with the high level objects and often by making software modifications at the software coding level. The program code is then generated for the service, which can be executed at an SCP.
The SCE refers to this program code as a SLP, while each of the high-level software components is referred to as a SIB. SLPs provide the "glue" logic and overall program flow to join SIBs together into meaningful services. Service Independent Building Blocks (SIB) The IN standards define a number of SIBs. Each SIB identifies a common telephony function that is used across services. Within each SIB, one or more operations take place to implement the SIB function. One of the SCE's goals is to implement the SIB, or the operations that comprise an SIB, and allow them to be joined together to create a service. SIBs are currently quite generic and lack ample detail, making them primarily useful only for high-level modeling of service functions. An example of some SIBs include: • Charge • Join • Screen • Translate • User Interaction These building blocks are easily recognizable as part of standard telephony call and feature processing. A complete list of SIBs can be found in the ITU IN specifications. To explore a specific example, consider the User Interaction SIB. The two most common functions involving User Interaction are collecting information from the user and playing audible messages (or tones). Audible messages can be used for a number of different purposes, including the following: • Prompts that request information from the user • Messages that provide information to the user • Branding or advertisement • Voicemail • Custom messages that are created by the service subscriber Input is collected to make decisions about how a call should be directed and to determine the services the user needs. User input is usually provided in one of the following forms: • DTMF digits using the phone keypad • Voice Recognition
• Web interface (Internet telephony) Figure 11-23 shows an exchange between the SSP and SCP that requires the user to enter information based on voice prompts. These actions are driven by the User Interaction SIB functions, which are implemented at the SCP as part of the service. Figure 11-23. Example of User Interaction The operation within the User Interaction SIB that implements the collection of digits does not determine how the digits will be used. That would defeat the SIB's "independence" aspect. As the network and services evolve, new means for interacting with the user will inevitably surface, thereby adding additional operations to the User Interaction SIB. Services that use new protocols, such as Wireless Access Protocol (WAP), have already changed User Interaction to some extent. However, the fundamental building block of this SIB will still be needed. Service Logic Programs (SLP) The SLP is the executable logic that results from the service creation process. Whether the service is constructed using graphical tools or programming libraries, the end result must be able to run on the SCP platform. The SCE allows subcomponents that make up an SIB to be joined together in a logical flow with decision branch points based on the results of the subcomponent operations. The result is a complete logic program that can be executed. Before running it on an SCP platform, the SCE generally provides some level of simulation to determine how the service will function. Good simulators allow phone calls to be placed using resources such as recorded announcements and Voice Recognition Units, to provide a complete simulation of the service. When the service has been constructed using the SCE tools, code modules or program scripts that are eventually deployed to the SCP or Adjunct are generated. The code modules are triggered by incoming messages, which match a given criteria for the script, from the SSP. The SLP processes the incoming messages from the SSP, accesses data that is
stored at the SCP, and makes decisions about how to direct call processing at the SSP.

CÓ THỂ BẠN MUỐN DOWNLOAD