ATIS 1000027-2008 Operator Services in a Next Generation Network (NGN) Environment.pdf

1、 TECHNICAL REPORT ATIS-1000027 OPERATOR SERVICES IN A NEXT GENERATION NETWORK (NGN) ENVIRONMENT ATIS is the leading technical planning and standards development organization committed to the rapid development of global, market-driven standards for the information, entertainment and communications in

2、dustry. More than 200 companies actively formulate standards in ATIS 17 Committees, covering issues including: IPTV, Cloud Services, Energy Efficiency, IP-Based and Wireless Technologies, Quality of Service, Billing and Operational Support, Emergency Services, Architectural Platforms and Emerging Ne

3、tworks. In addition, numerous Incubators, Focus and Exploratory Groups address evolving industry priorities including Smart Grid, Machine-to-Machine, Networked Car, IP Downloadable Security, Policy Management and Network Optimization. ATIS is the North American Organizational Partner for the 3rd Gen

4、eration Partnership Project (3GPP), a member and major U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications Sectors, and a member of the Inter-American Telecommunication Commission (CITEL). ATIS is accredited by the American National Standards Institute (A

5、NSI). For more information, please visit . Notice of Disclaimer the calling party is informed that the number is no longer in service and the reason why it is not in service. The calling party may also be informed of a new working telephone number and the call may be completed to the new number. 2.5

6、.4 Handling of Restricted Lines Calls from certain restricted lines are forwarded to an operator for special handling. 3 NGN/IP Architecture In this Technical Report (TR), the network architecture that provides the context for Operator Services is taken from the ATIS Technical Report on NGN Architec

7、ture ATIS-1000018 with the assumption that the Operator Services System will be a part of a Voice over IP (VoIP) network. 3.1 Terminology The following terms are used in this document. Operator Services The set of services currently accessed by dialing 411, NPA-555-1212, 0+10 digits, or 0- (i.e., th

8、e zero digit with no further dialing). Note that some or all of the services in the set may also be accessed via other dialing patterns. Operator Services Provider (OSP) - The OSP is the provider of operator services to end users. The OSP provides retail services directly to end users, and provides

9、wholesale services to other Services Providers, such as a Home Services Provider or Aggregation Services Provider. ATIS-1000027 4 Specifically, the OSP provides services to the end users that are served by Home Services Providers. The OSP needs to identify the Home Services Provider in order to prov

10、ide such services as customized announcements, and may also need to know the identity of other intermediate entities for billing purposes. Home Services Provider (HSP) - The HSP is the subscribed provider of voice services to the calling end user. In the case of a roaming mobile end user, the HSP ma

11、y not be the network that originates the call. However, recognizing that current call setup procedures route such calls through the HSP, this TR assumes that all calls appear to the Operator Service as having originated in the HSPs network. The HSP may be directly connected to the OSP or may communi

12、cate with the OSP via an Aggregation Services Provider. The HSP may also be an Aggregation Services Provider or OSP. Aggregation Services Provider - The Aggregation Services Provider is the provider that routes DA calls from multiple HSPs to a DA provider. The Aggregation Services Provider may be an

13、 HSP and an HSP may send traffic to a single DA provider using multiple Aggregation Services Providers. 4 Application of NGN Architecture to the Operator Services System Figure 1 illustrates the application of the NGN/IP architecture to operator services, based on the ATIS NGN Architecture ATIS-1000

14、018. Most naturally and flexibly, one can think of an Operator Services System (OSS) within the general VoIP architecture context of application servers and media servers. Incoming calls may be first signaled to the operator services Application Server (AS), which contains OSS application logic and

15、distributes calls to operator services Media Servers (MS) that interact with the caller and work with the AS to handle the calls. Calls may, for example, be completed to called parties, or may be transferred from one type of MS to another. ATIS-1000027 5 MGIP PhoneVoIPProviderPSTNSS7WirelessBearer (

16、RTP/IP)Signal (SIP)VoIP - Operator Services Interconnection Reference DiagramSignalingSGOSS(PSTN)dbASMSdbOSS(VoIP)datanetworkdataBearer (Circuit)xxxxxxxxxxxxxxxxxxxFigure 1: VoIP Services Interconnection Reference Diagram In Figure 1: AS = Operator services Application Server, in this case containin

17、g operator services applications MS = Operator services Media Server, in this case supporting media interactions for operator services OSS = Operator Services System db = One of the variety of databases supporting Operator Services, some may be considered to be part of the OSS, some may be considere

18、d to be external to it MG = Media (trunking) Gateway SG = Signaling Gateway The OSS may have multiple of any of the AS, MS or database (db) components, i.e., any of these functions may be distributed across multiple physical elements. The OSS may be hosted by or resident within a VoIP Provider netwo

19、rk different from the one serving the caller. There may be multiple types of operator services MSes with different capability sets; for example, one that does simple speech recognition and another that does more sophisticated ATIS-1000027 6 recognition; or one that specializes in domestic calls and

20、another that specializes in international calls. Calls may be moved from one type of MS to another. Human attendant resources (e.g., the functions currently performed by an operator position in the PSTN, involving both a workstation and a human agent) are logically considered part of an MS. An MS ma

21、y include zero, one, or more pools of human attendant resources, or an MS may include a single human attendant resource. This concept is explored in more detail in sections 4.1.1 through 4.1.3. The OSS components may be distributed or co-located. They may reside within a VoIP network, or some or all

22、 of the components may be third-party. The figure as shown assumes that the OSS relies on a VoIP network to route and distribute calls among the various MSes. However, it may also be the case that the OSS includes its own internal fabric/network for such routing. A set of MSes could be part of a poo

23、l of media servers shared with other applications. The figure also shows a PSTN (circuit switched) OSS, because interworking between VoIP OSSes and PSTN OSSes may be necessary (e.g. for internal call transfers between an operator and a supervisor). Call origination and completion may occur from/to V

24、oIP or PSTN endpoints, so the ability to interwork across a VoIP/PSTN boundary is critical. While the data network used by the AS, MS and db to communicate is shown as being separated, it could be part of the overall IP network that includes the VoIP network. Discussion of the dbs is out of scope of

25、 this TR. Thus, interactions with databases for real time rating, rate quotes, card validation and management, line information (e.g., LIDB) etc. are not covered here. Additionally, discussion of generic MS-MS data communication is outside the scope of this TR. 4.1 General VoIP Call Flow Involving O

26、SS Figure 2 below provides an illustrative call flow to a VoIP OSS. In this description, it is assumed that the OSS is within the trust domain of a VoIP service providers network (see section 4.1.15 for third Party OSS considerations). Network details not essential to understanding the role of the O

27、SS and operator services support are omitted. SIP signaling enables all of what is described in the call flow to occur. However, SIP signaling details are not provided in this call flow. Note that all SIP signaling among the AS, MSes and Border Elements (BEs) occurs through the Call Session Control

28、Function (CSCF). ATIS-1000027 7 callingVoIP PhoneVoIP service providerNetworkBearer (RTP/IP)Signaling (SIP)dbASMS1dbOSS(VoIP)data networkdataVoIP accessnetworkBE1CSCFMSKBE2calledVoIP PhoneVoIP egressnetworkFigure 2: General Call Flow Network Diagram 1. A calling party originates an operator services

29、 call from a VoIP phone, which sends a SIP INVITE message. SIP signaling proceeds through the VoIP access network and BE1to the CSCF, which determines based on the destination address that the call should be handled by an AS. The destination address could be, e.g., a telephony type number toll-free

30、number in tel url format, or it could be a SIP URI such as . The CSCF may rely on some ancillary db or service broker function to help it determine the particular AS that is to be invoked. 2. The CSCF signals to the AS. Note that the following information currently signaled in the PTSN environment d

31、oes not have analogies in VoIP signaling: - something that is specifically the callers Billing Number (akin to the ISUP Charge Number) - originating line information (akin to ISUP OLI information) 3. The AS, acting as a SIP Back to Back User Agent (B2BUA) coordinates connecting a bearer path from th

32、e calling party to MS1, in order to prompt the caller for additional information. 4. The AS instructs the MS1to perform a prompt and collect routine with the caller, e.g., a main menu through which the caller indicates what service and what language. MS1returns results to the AS. ATIS-1000027 8 5. T

33、he AS determines that a different MS, viz. MSK, is required to further service the caller. (MSKmay, for example, have live operators that specialize in Swahili, which is what the caller requested.) The AS causes the bearer path to MS1to be dropped by sending a SIP BYE toward MS1. 6. The AS causes th

34、e caller leg to be connected to MSKby sending a SIP Re-INVITE toward the calling party and an INVITE toward MSK. The Re-INVITE travels (through the CSCF) to BE1, which handles it. 7. The AS provides instructions to MSKregarding interactions with the caller, and MSKreturns results. 8. The AS causes t

35、he leg to MSKto be dropped by sending a SIP BYE toward MSK. Assume that in this call flow the service requires call completion to a called party, e.g., this could be DA Call Completion, or card-billed, or call collect, etc. 9. The AS causes the caller leg (from BE1) to be connected to the called par

36、ty, using another SIP Re-INVITE toward the calling party and a new INVITE toward the called party. The CSCF routing function determines the egress BE, viz. BE2, to be used reach the called party. 10. The INVITE reaches the called party VoIP Phone, which accepts the call. Upon exchange of SDP informa

37、tion in the SIP signaling messages, the media path is set up between the two end parties. Note that from a signaling control point of view, the AS has remained on the call. 11. At some point the call ends. This call flow assumes that the called party clears, but the caller stays on the line. A SIP B

38、YE is received by the AS through BE2for the called leg, and that call leg is cleared.112. The AS can decide what to do next, e.g., clear the calling party leg, or bring that leg back to an MS for some purpose such as giving the caller a menu of options. 4.1.1 Modeling the Workstation as a Media Serv

39、er Todays operator workstation (WS), typically including a human agent, interacts with a caller and performs application logic, e.g., in determining when to make a new call to a third party for billing verification. This section discusses how to model such a workstation within the framework of the A

40、TIS NGN architecture as one type of Media Server. Note that a very simple prompt and collect MS, without involvement of a human agent, and a workstation-type MS, with a human agent, should be viewed as examples of MSes on an MS continuum of sophistication. Depending on the scope of service provided,

41、 a WS-type MS may be more or less sophisticated. As such, it is recognized that A MS within the NGN architecture framework may contain application logic. Whether that application logic is carried out by a human agent or software or a combination is not relevant for NGN architecture concerns. How tha

42、t application logic is obtained by the MS (e.g., fetched, cached or provisioned or comes in the brain of a human agent) is not relevant for NGN architecture concerns. 1This example call flow does not illustrate the option that the AS could remove itself from the call path at some point after step 10

43、 (when the call is established between the other two parties) and the end of the call. ATIS-1000027 9 It is expected that any application logic in the MS does not work at cross-purposes with that in a controlling AS. It is also recognized that extensions to the concepts of Media Resource Broker (MRB

44、) and AS-MS control, as delineated in the NGN architecture standard ATIS-1000018, may be needed to cover the WS case. 4.1.2 Call Distribution among MSes and among Agent Positions In general, the VoIP architecture allows for efficient call distribution among pools of MSes. Depending on the level of s

45、ophistication desired, different methods can be employed. For example, An AS could provide different logical MS addresses to the Call Session Control Function (CSCF) functional element, which the CSCF would then use to route to calls to different MSes. The AS could use different logical addresses to

46、 implicitly identify different MS capability sets needed on calls. The routing capability within the CSCF itself could use the same MS address supplied by an AS for multiple calls to select among and route to mulitple MSes that are functionally equivalent. The network could employ a scheme that has

47、knowledge of current resource utilization across the pool of MSes. For example, the AS could request assignment of an MS with particular attributes from an MRB (not shown in the figures). The role of the MRB is to know status of MS resources and support requests for MS resources. The AS would then r

48、oute the call to the particular MS identified by the MRB. Any given MS may employ local algorithms for call distribution among its internal resources, which, as noted earlier, may include pools of human attendant resources. Attributes of a WS-type MS may include operator characteristics (e.g., a par

49、ticular skill set representing the capabilities of the human operator currently using the particular workstation). The attributes of a WS-type MS may also change much more dynamically than for a typical automated MS, e.g. due to operator shift changes or breaks, or movement of a human operator from one physical workstation to another. The MRB concept acknowledges an operations support system feed to acquire knowledge of MSes and their attributes. Extension of the definition of the MRB to include other methods, such as SIP Registration or