INTERNATIONAL TELECOMMUNICATION UNION
`
`)45 4
`
`TELECOMMUNICATION
`STANDARDIZATION SECTOR
`OF ITU
`
`1(cid:14)(cid:17)(cid:18)(cid:17)(cid:17)
`(03/93)
`
`’%.%2!,2%#/--%.$!4)/.3/.4%,%0(/.%
`37)4#().’!.$3)’.!,,).’
`).4%,,)’%.4.%47/2+
`
`).42/$5#4)/.4/).4%,,)’%.4.%47/2+
`#!0!"),)493%4(cid:17)
`
`)45 42ECOMMENDATION1(cid:14)(cid:17)(cid:18)(cid:17)(cid:17)
`
`(Previously “CCITT Recommendation”)
`
`Bright House Networks - Ex. 1020, Page 1
`
`

`
`FOREWORD
`
`The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of the International Telecom-
`munication Union. The ITU-T is responsible for studying technical, operating and tariff questions and issuing
`Recommendations on them with a view to standardizing telecommunications on a worldwide basis.
`
`The World Telecommunication Standardization Conference (WTSC), which meets every four years, established the
`topics for study by the ITU-T Study Groups which, in their turn, produce Recommendations on these topics.
`
`ITU-T Recommendation Q.1211 was prepared by the ITU-T Study Group XI (1988-1993) and was approved by the
`WTSC (Helsinki, March 1-12, 1993).
`
`___________________
`
`NOTES
`
`As a consequence of a reform process within the International Telecommunication Union (ITU), the CCITT
`1
`ceased to exist as of 28 February 1993. In its place, the ITU Telecommunication Standardization Sector (ITU-T) was
`created as of 1 March 1993. Similarly, in this reform process, the CCIR and the IFRB have been replaced by the
`Radiocommunication Sector.
`
`In order not to delay publication of this Recommendation, no change has been made in the text to references containing
`the acronyms “CCITT, CCIR or IFRB” or their associated entities such as Plenary Assembly, Secretariat, etc. Future
`editions of this Recommendation will contain the proper terminology related to the new ITU structure.
`
`In this Recommendation, the expression “Administration” is used for conciseness to indicate both a
`2
`telecommunication administration and a recognized operating agency.
`
`All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronic or
`mechanical, including photocopying and microfilm, without permission in writing from the ITU.
`
`ª ITU 1993
`
`Bright House Networks - Ex. 1020, Page 2
`
`

`
`Recommendation Q.1211 (03/93)
`
`CONTENTS
`
`4
`5
`5.1
`
`SUMMARY ..............................................................................................................................................................
`1
`Introduction ....................................................................................................................................................
`2
`Phased standardization ...................................................................................................................................
`3
`General description and scope of CS-1 ..........................................................................................................
`3.1
`Criteria for CS-1 ...............................................................................................................................
`3.2
`Evolution of CS-1 .............................................................................................................................
`Overview of CS-1 Recommendations............................................................................................................
`Service aspects ...............................................................................................................................................
`Type A and Type B services ..........................................................................................................................
`5.2
`Target sets of CS-1 services and service features .............................................................................
`5.3
`Network support of CS-1 services....................................................................................................
`Network aspects .............................................................................................................................................
`6.1
`Network functions ............................................................................................................................
`6.2
`Control architecture principles..........................................................................................................
`6.3
`Feature interactions...........................................................................................................................
`6.4
`Consistency among CS-1 supported service features .......................................................................
`Functional relationships and interfaces ..........................................................................................................
`7.1
`Reference points and identifiers for functional relationships ...........................................................
`7.2
`Control classes ..................................................................................................................................
`7.3
`Reference point identifiers and control relationships .......................................................................
`7.4
`CS-1 non-IN connection and call control .........................................................................................
`7.5
`CS-1 IN service control ....................................................................................................................
`7.6
`Service management for CS-1 ..........................................................................................................
`7.7
`Network interworking in CS-1 .........................................................................................................
`7.8
`Summary of CS-1 control relationships............................................................................................
`Annex A – Examples of relationships and mappings between CS-1 services and service features ..........................
`Annex B – Short prose descriptions of targeted services and service features..........................................................
`B.1
`Descriptions of targeted services ......................................................................................................
`B.2
`Descriptions of targeted service features ..........................................................................................
`
`6
`
`7
`
`Page
`ii
`1
`1
`1
`1
`2
`3
`3
`3
`4
`4
`5
`5
`7
`9
`9
`10
`10
`10
`10
`11
`12
`12
`13
`15
`16
`18
`18
`26
`
`Recommendation Q.1211 (03/93)
`
`i
`
`Bright House Networks - Ex. 1020, Page 3
`
`

`
`SUMMARY
`
`Intelligent network capability set 1 is the first standardized stage of the intelligent network (IN) as an architectural
`concept for the creation and provision of telecommunications services. This Recommendation gives an introduction to
`capability set 1 (CS-1) by providing an overview and definition of CS-1 and by describing its main characteristics and
`overall capabilities. It defines the service aspects, network aspects and functional relationships that form the basis of the
`CS-1 capabilities.
`
`This Recommendation is the first in the Q.121x-Series Recommendations devoted to CS-1. It builds on the architectural
`principles of IN as described in the Q.120x-Series Recommendations.
`
`The CS-1 Recommendations (Q.121x-Series) form a useful basis for achieving implementation experience. As with any
`project of this size and complexity, it can be anticipated that there may be some difficulties in interworking the various
`implementations of IN CS-1 physical elements. In order that the IN objective for working in a multi-vendor environment
`may be fully achieved, the IN CS-1 Recommendations text may go through some future revision in the light of
`implementation experience.
`
`ii
`
`Recommendation Q.1211 (03/93)
`
`Bright House Networks - Ex. 1020, Page 4
`
`

`
`Recommendation Q.1211
`
`INTRODUCTION TO INTELLIGENT NETWORK CAPABILITY SET 1
`
`(Helsinki, 1993)
`
`1
`
`Introduction
`
`Intelligent network capability set 1 is the first standardized stage of the intelligent network (IN) as an architectural
`concept for the creation and provision of telecommunications services. This Recommendation gives an introduction to
`capability set 1 (CS-1) by providing an overview and definition of CS-1 and by describing its main characteristics and
`overall capabilities.
`
`2
`
`Phased standardization
`
`The intelligent network (IN) is an architectural concept for creation and provisioning of new services which is
`characterized by:
`
`a)
`
`b)
`
`extensive use of information processing techniques;
`
`efficient use of network resources;
`
`c) modularization and reusability of network functions;
`
`d)
`
`e)
`
`f)
`
`g)
`
`h)
`
`i)
`
`j)
`
`integrated service creation and implementation by means of modularized, reusable network functions;
`
`flexible allocation of network functions to physical entities;
`
`portability of network functions among physical entities;
`
`standardized communications between network functions via service independent interfaces;
`
`service subscriber’s control of some subscriber-specific service attributes;
`
`service user control of some user-specific attributes;
`
`standardized management of service logic.
`
`The implementation of the IN architecture will facilitate the rapid introduction of new services. Its architecture can be
`applied to various types of telecommunications networks, which include: public switched telecommunications network
`(PSTN), public switched packet data network (PSPDN), mobile, and integrated services digital networks (N- and
`B-ISDN).
`
`The ultimate IN is an evolving target, therefore in order to take full advantage of the technological possibilities at a
`given point in time it is necessary to define specific phases in the evolution to a target architecture. This phased approach
`is shown in Figure 1.
`
`This Recommendation provides the description of CS-1 at time T1 as represented in Figure 1.
`
`3
`
`General description and scope of CS-1
`
`3.1
`
`Criteria for CS-1
`
`CS-1 defines an initial subset of IN capabilities that meet the following general criteria:
`
`a) CS-1 is a subset of the target intelligent network architecture;
`
`b) CS-1 is a set of definitions of capabilities that is of direct use to both manufacturers and network
`operators;
`
`Recommendation Q.1211 (03/93)
`
`1
`
`Bright House Networks - Ex. 1020, Page 5
`
`

`
`Capabilities
`sets
`
`CS x
`
`CS2
`
`CS1
`
`1
`
`1
`
`2
`
`3
`
`1
`
`2
`
`3
`
`1
`
`2
`
`3
`
`T1
`
`T2
`
`Tx
`
`T1137310-91/d01
`
`Time
`
`IN concept and modelling
`
`Definition of next CS
`
`Recommendation for CS-X
`
`1 2 3
`
`Areas:
`
`FIGURE 1/Q.1211
`Sequencing of capability sets
`
`FIGURE 1/Q.1211...[D01] = 12 CM (118%)
`
`c) CS-1 provides network capabilities to support services either defined or in the process of being defined by
`CCITT (e.g. universal personal telecommunications service, freephone, and virtual private network
`services such as private numbering plan). CS-1 also provides capabilities to support the introduction of
`services which may neither be standardized by CCITT, nor be part of the proposed set of targeted
`services;
`
`d) CS-1 is the first standardized stage of evolution based upon the existing technology base and on
`evolvability requirements addressed in 3.2.
`
`The CS-1 architecture may be supported over PSTN, ISDN, and mobile networks.
`
`3.2
`
`Evolution of CS-1
`
`The CS-1 Recommendations (Q.121x-Series) form a useful basis for achieving implementation experience. As with any
`project of this size and complexity, it can be anticipated that there may be some difficulties in interworking the various
`implementations of IN CS-1 physical elements. In order that the IN objective for working in a multi-vendor environment
`may be fully achieved, the IN CS-1 Recommendations text may go through some future revision in the light of
`implementation experience.
`
`The CS-1 architecture takes into account the evolution requirement, i.e., it supports the CS-1 targeted services but its
`functionalities are designed to evolve towards the future capability sets (CS-2 and beyond). Therefore, the CS-1
`capabilities are defined without any assumptions that are known to limit their ability to evolve into future capability sets.
`
`2
`
`Recommendation Q.1211 (03/93)
`
`Bright House Networks - Ex. 1020, Page 6
`
`

`
`4
`
`Overview of CS-1 Recommendations
`
`Table 1 contains an overview of the Recommendations that are specifically related to CS-1:
`
`TABLE 1/Q.1211
`
`CS-1 Recommendations
`
`Recommendation
`
`Title
`
`Q.1211
`Q.1213
`Q.1214
`Q.1215
`Q.1218
`Q.1219
`
`Introduction to intelligent network capability set 1
`Global functional plane for intelligent network CS-1
`Distributed functional plane for intelligent network CS-1
`Physical plane for intelligent network CS-1
`Intelligent network interface specifications for capability set 1
`Intelligent network users guide for capability set 1
`
`5
`
`Service aspects
`
`Although, by nature, the IN is a service independent architecture, it is relevant to describe the general CS-1 service
`capabilities. The services and service features that are to be supported by CS-1 are fundamental to the CS-1 service
`independent building blocks (SIBs), call processing model and service control principles.
`
`5.1
`
`Type A and Type B services
`
`CS-1 capabilities are intended to support services and service features that fall into the category of “single ended”,
`“single point of control” services referred to as Type A, while all other services are placed in a category called Type B.
`The following definitions apply:
`
`A single-ended service feature applies to one and only one party in a call and is orthogonal (independent) at both the
`service and topology levels to any other parties that may be participating in the call. Orthogonality allows another
`instance of the same or a different single-ended service feature to apply to another party in the same call as long as the
`service feature instances do not have feature interaction problems with each other.
`
`Single point of control describes a control relationship where the same aspects of a call are influenced by one and only
`one service control function at any point in time (see also 6.2.1).
`
`CS-1 standards do not encompass “Type B” services for the following reasons:
`
`a) Operational complexity
`
`In Type B services, several IN subscribers may be associated within a single call. During the call,
`subscribers may be added or dropped. These associations take place physically in the switches involved in
`the call (SSF/CCF functions) under the control of an SCF. The SCF will need rules to handle feature
`arbitration between subscribers involved in the call (e.g. incompatible screening lists). This may have to
`involve real-time consultations between the SCFs that “represent” the various parties involved in the call.
`Rules will also be required to handle topological decisions (e.g. which physical switches should be chosen
`to “join” groups of subscribers scattered around a network?).
`
`Recommendation Q.1211 (03/93)
`
`3
`
`Bright House Networks - Ex. 1020, Page 7
`
`

`
`b)
`
`Implementation complexity
`
`Type B services may involve manipulation of switch connection resources by service logic located in an
`SCF. This means that an “abstracted” view of the switch’s connection resources must be made available
`to external service logic. Models have been formulated to accommodate appropriate “abstracted” views,
`but to date these are theoretical proposals. A very large investment in switch software redesign may be
`required to realize such models. In contrast, the switch software modifications to accommodate Type A
`services are relatively modest in scope and are well understood.
`
`c) Control complexity
`
`Type A services are characterized by a relatively simple control relationship between SSF and SCF. The
`SSF is a “client” for service-related information provided by the SCF, however, the switch retains
`connection control at all times.
`
`In contrast, the control relationship between SCF and SSF in Type B services may require the sharing of
`connection control between the switch and external service logic. The information flows need to be rich
`in parameters to manage what is essentially a peer-peer, distributed processing relationship.
`
`As there are considerable differences in operational, implementation, and control complexity between Type A and Type
`B services, CS-1 is targeted to support Type A services only.
`
`There are some circumstances in which it will be possible to apply “Type A” IN technology to certain aspects of
`“Type B” services. This applies to switch-based services in general, whether these services be of “Type A” or “Type B”,
`and to “Type B” services in general, whether these be switch-based or CS-x based. Further detail can be obtained from
`Recommendation Q.1214.
`
`5.2
`
`Target sets of CS-1 services and service features
`
`Tables 2 and 3 contain the target sets of CS-1 services and service features. The target sets can be used to identify and
`verify the service-independent capabilities of CS-1. Examples of relationships and mappings between these CS-1
`services and service features are shown in Annex A.
`
`Annex B provides short prose descriptions of targeted services and service features. These were used to develop the
`current Q.121x-Series Recommendations as CS-1 is intended to support evolutionary new services. The descriptions
`provided for the targeted services and service features are for the above-mentioned purposes only and are not to be used
`by service designers for service creation.
`
`Definitions of “service” and “service feature”:
`
`A service is a stand-alone commercial offering, characterized by one or more core service features, and can be optionally
`enhanced by other service features.
`
`A service feature is a specific aspect of a service that can also be used in conjunction with other services/service features
`as part of a commercial offering. It is either a core part of a service or an optional part offered as an enhancement to a
`service.
`
`5.3
`
`Network support of CS-1 services
`
`The services are to be supported over various networks. For IN CS-1 applications the following networks are
`considered:
`
`i)
`
`PSTN;
`
`ii)
`
`ISDN (Public and private networks);
`
`iii) PLMN.
`
`4
`
`Recommendation Q.1211 (03/93)
`
`Bright House Networks - Ex. 1020, Page 8
`
`

`
`TABLE 2/Q.1211
`
`Target set of CS-1 services
`
`Abbreviated dialling
`Account card calling
`Automatic alternative billing
`Call distribution
`Call forwarding
`Call rerouting distribution
`Completion of call to busy subscribera)
`Conference callinga)
`Credit card calling
`Destination call routing
`Follow-me diversion
`Freephone
`Malicious call identification
`Mass calling
`Originating call screening
`Premium rate
`Security screening
`Selective call forward on busy/don’t answer
`Split charging
`Televoting
`Terminating call screening
`Universal access number
`Universal personal telecommunications
`User-defined routing
`Virtual private network
`
`ABD
`ACC
`AAB
`CD
`CF
`CRD
`CCBS
`CON
`CCC
`DCR
`FMD
`FPH
`MCI
`MAS
`OCS
`PRM
`SEC
`SCF
`SPL
`VOT
`TCS
`UAN
`UPT
`UDR
`VPN
`
`a) These services and service features might be partially supported in CS-1, because they require, beyond Type A capabilities,
`additional Type B capabilities. Parts of these service and service features are considered in CS-1 as long as these parts belong
`to Type A and do not impose capabilities additional to those required for other services and service features in the list.
`NOTES
`1 Above service names apply to the descriptions of targeted services (see Annex B), and not to the user-network interface
`descriptions provided by CCITT SG I.
`2 Network implementation aspects may be important for some services.
`
`6
`
`Network aspects
`
`This clause provides an overview of the IN network functions, and sets guidelines for the control architecture of CS-1. It
`also describes how the issues of feature interaction and service-feature consistency are handled in CS-1.
`
`Figure 2 summarizes the IN network functions and their functional relationships.
`
`6.1
`
`Network functions
`
`The network functions are described here.
`
`6.1.1
`
`Call control related functions
`
`SSF – service switching function – this function interfaces with CCF and SCF. It allows the CCF to be directed by
`the SCF.
`
`SRF – specialized resources function – this function provides a category of resources for access by other network
`entities. Examples of resources include DTMF sending and receiving, protocol conversion, speech recognition,
`synthesized speech provision, etc.
`
`CCF – call control function – this function refers to call and connection handling in the classical sense (e.g., that of an
`exchange).
`
`CCAF – call control agent function – this function provides the user access to the network.
`
`Recommendation Q.1211 (03/93)
`
`5
`
`Bright House Networks - Ex. 1020, Page 9
`
`

`
`TABLE 3/Q.1211
`
`Target set of CS-1 service features
`
`Abbreviated dialling
`Attendant
`Authentication
`Authorization code
`Automatic call backa)
`Call distribution
`Call forwarding
`Call forwarding on BY/DA
`Call gapping
`Call hold with announcementa)
`Call limiter
`Call logging
`Call queueing
`Call transfera)
`Call waitinga)
`Closed user group
`Consultation callinga)
`Customer profile management
`Customized recorded announcement
`Customized ringing
`Destinating user prompter
`Follow-me diversion
`Mass calling
`Meet-me conferencea)
`Multi-way callinga)
`Off net access
`Off net calling
`One number
`Origin dependent routing
`Originating call screening
`Originating user prompter
`Personal Numbering
`Premium charging
`Private numbering plan
`Reverse charging
`Split charging
`Terminating call screening
`Time dependent routing
`
`ABD
`ATT
`AUTC
`AUTZ
`ACB
`CD
`CF
`CFC
`GAP
`CHA
`LIM
`LOG
`QUE
`TRA
`CW
`CUG
`COC
`CPM
`CRA
`CRG
`DUP
`FMD
`MAS
`MMC
`MWC
`OFA
`ONC
`ONE
`ODR
`OCS
`OUP
`PN
`PRMC
`PNP
`REVC
`SPLC
`TCS
`TDR
`
`a) These services and service features might be partially supported in CS-1, because they require, beyond Type A capabilities,
`additional Type B capabilities. Parts of these service and service features are considered in CS-1 as long as these parts belong
`to Type A and do not impose capabilities additional to those required for other services and service features in the list.
`NOTE – Above service feature names apply to the descriptions of targeted service features (see Annex B), and not to the user-
`network interface descriptions provided by CCITT SG I.
`
`6.1.2
`
`Service control related functions
`
`SCF – service control function – this function contains the IN service logic and handles service-related processing
`activity.
`
`SDF – service data function – this function handles access to service-related data and network data and provides
`consistency checks on data. It hides from the SCF the real data implementation and provides a logical data view to SCF.
`
`6.1.3
`
`Management related functions
`
`SCEF – service creation environment function – this function allows an intelligent network service to be defined,
`developed, tested and input to the SMF. The output of this function involves service logic and service data templates.
`
`6
`
`Recommendation Q.1211 (03/93)
`
`Bright House Networks - Ex. 1020, Page 10
`
`

`
`SMF
`
`All other
`network functions
`except CCAF
`
`SMAF
`
`SCEF
`
`SCF
`
`SDF
`
`SRF
`
`CCAF
`
`SSF
`
`CCF
`
`SSF
`
`CCF
`
`CCF
`
`CCAF
`
`T1145680-92/d02
`
`CCAF
`CCF
`SCEF
`SCF
`SDF
`SMAF
`SMF
`SRF
`SSF
`
`Call control agent function
`Call control function
`Service creation environment function
`Service control function
`Service data function
`Service management access function
`Service management function
`Specialised resource function
`Service switching function
`
`FIGURE 2/Q.1211
`IN functions and functional relationships
`
`FIGURE 2/Q.1211...[D02] = 15.5 CM (118%)
`
`SMAF – service management access function – this function provides an interface (e.g. screen presentation, ...) to
`the SMF.
`
`SMF – service management function – this function involves service management control, service provision control and
`service deployment control.
`
`6.2
`
`Control architecture principles
`
`As stated in 5 (Service aspects), the service scope of CS-1 shall be restricted to single-ended, single-point-of-control
`services. This subclause identifies principles for the control architecture of CS-1, in the context of this service scope.
`
`This subclause is organized around three control aspects:
`
`–
`
`–
`
`–
`
`service invocation and control;
`
`end-user interaction with the SRF, and
`
`service management.
`
`Recommendation Q.1211 (03/93)
`
`7
`
`Bright House Networks - Ex. 1020, Page 11
`
`

`
`6.2.1
`
`Service invocation and control
`
`This control aspect involves the CCF, SSF and SCF. It will be illustrated by considering an originating CS-1 call.
`
`A CS-1 service request from a calling party will typically consist of an off-hook, and/or an appropriate sequence of
`dialled digits. The CCF has no CS-1 service “knowledge”, but is programmed to recognize that a CS-1 service request
`has taken place. It temporarily suspends call processing on behalf of the calling party, and passes appropriate call state
`information to the SSF.
`
`The SSF is tightly coupled to the CCF, and in CS-1, it is expected that these two functions will constitute a
`single-vendor package. The role of the SSF is to interpret the service request and call state information, build a
`standardized query, and send the query via a standard protocol to the SCF.
`
`SCF receives and decodes the query, and interprets it in the context of a CS-1 supported service. It formulates, encodes
`and sends a standardized response to the SSF. The formulation of the response may involve complex service logic
`leading to translations, the invocation of a prompt and collect sequence with the calling party (see also 6.2.2), or a query
`to a separate SDF.
`
`The SSF receives, decodes and interprets the SCF’s response. It then provides explicit instructions to the CCF on how to
`complete the call set-up process on behalf of the end-user.
`
`The following points capture key principles for CS-1:
`
`1) The CCF retains ultimate responsibility for integrity of, and control of, the local connection at all times.
`
`2) The SSF to SCF relationship is, by definition, service-independent. Therefore the CCF and SSF should
`never contain service logic specific to CS-1 supported services.
`
`3)
`
`In the event of SCF malfunction, or time-out in the SCF to SSF response, the SSF/CCF combination
`should be capable of reverting to a default call completion sequence, with appropriate announcement(s) to
`the calling and/or called party.
`
`4) The SSF should never have to interact with more than one SCF at any given time in order to complete a
`sequence of query/response interactions on behalf of a calling or called party. In other words, the SCF
`should be a “single point of contact” for the SSF at any given time.
`
`5) Call hand-offs (transfer of responsibility) between SCFs, and between SSFs are permitted in CS-1.
`However, the hand-off must be explicit, and must not violate principle 4).
`
`6.2.2
`
`End-user (calling or called party) interaction with the SRF
`
`As part of the process of formulating a response to the SSF, the SCF may need to enter into a dialogue with the calling
`or called party. This would typically take the form of a prompt and collect sequence.
`
`The SCF in CS-1 does not have the physical means to enter into this dialogue directly. Instead, it instructs the SRF to
`carry out a prompt and collect sequence with the calling or called party on its behalf.
`
`In this typical scenario, the SCF would instruct the SSF to connect the end-user to an appropriate physical resource
`(e.g. a voice announcement system) within the SRF. It would also instruct the SRF on the particular prompt and collect
`sequence required. The SCF would then temporarily suspend processing of the call.
`
`The SRF would activate the prompt and collect sequence, and enter into a dialogue with the calling or called party. The
`response (e.g. a personal identification number) would be encoded and returned to the SCF, and the voice connection to
`the SRF would be dropped. The SCF would then resume its service control sequence as outlined in 6.2.1.
`
`8
`
`Recommendation Q.1211 (03/93)
`
`Bright House Networks - Ex. 1020, Page 12
`
`

`
`The following points capture key principles for CS-1:
`
`6) The SCF has full IN-supported service control of instruction formulation and sequencing with respect to
`the SRF and SSF.
`
`7) As a corollary to principle 6), there shall be no direct service control interaction between the SSF and
`SRF for CS-1 based services. The SSF and SRF have a peer-peer relationship for the control of CS-1
`based services, and both are subsidiary to the SCF.
`
`8) The SCF will require the capability of suspending processing of a CS-1 based service on behalf of a
`calling or called party, and then resuming on behalf of the same party at a later time.
`
`6.2.3
`
`Service management
`
`The control aspects covered in 6.2.1 and 6.2.2 address the real-time interactions between CS-1 functions on behalf of a
`particular calling or called party. In contrast, the service management aspect primarily addresses the network operator’s
`interaction with the SSF, SCF, SDF, and SRF. This interaction normally takes place outside the context of a particular
`call or service invocation.
`
`However, CS-1 must neither exclude nor constrain the capability of service customers to interact directly with customer-
`specific service management information (e.g. a personal service profile).
`
`The following points may be relevant to the CS-1 timeframe, but are not standardized in the CS-1 Recommendations:
`
`9) The SMF, SCEF, and SMAF may be used to add, change or delete CS-1 based service related information
`or resources in the SSF, SCF, SDF, and SRF. Such changes should not interfere with CS-1 based service
`invocations or calls that are already in progress.
`
`10) The network operator may, at its discretion, give the service customer the ability to add, change, or delete
`appropriate customer-specific information. The mechanisms and safeguards that are put into place by the
`network operator for this interaction may take advantage of CS-1 functions and capabilities.
`
`6.3
`
`Feature interactions
`
`The constraints placed on the CS-1 architecture have been put in place primarily to minimize and control feature
`interactions within single domains of responsibility.
`
`The single-endedness of CS-1 based services means that all aspects of a call are under the control of one CCF/SSF and
`one SCF at any point in time [principle 4]. The SSF is therefore responsible for the handling of interactions between
`CS-1 based SSF/CCF capabilities, and non-IN features already embedded in CCF software.
`
`The SSF/CCF functionality is expected to be implemented through a closely-coupled, single-vendor approach in CS-1.
`Therefore, this feature interaction problem will be constrained within single-vendor domains in CS-1, and will not
`require multi-vendor standards.
`
`6.4
`
`Consistency among CS-1 supported service features
`
`The ultimate responsibility for consistency of operations within a set of CS-1 based service features lies with the
`network operator. However, the software and data structures of the SCF, SDF, SMF and the tools provided by the SCEF,
`may be designed to aid the network operator in fulfilling this responsibility.
`
`These are new areas for the telecommunications industry and CS-1 Recommendations should not seek to control or
`constrain market-driven implementations of SMF, SMAF, or SCEF.
`
`Recommendation Q.1211 (03/93)
`
`9
`
`Bright House Networks - Ex. 1020, Page 13
`
`

`
`7
`
`Functional relationships and interfaces
`
`7.1
`
`Reference points and identifiers for functional relationships
`
`Figure 3 identifies the 13 distinct functional relationships (presented in Figure 2) as reference points:
`
`A. CCAF-CCF;
`
`B. CCF-CCF;
`
`C. CCF-SRF;
`
`D. SSF-SCF;
`
`E.
`
`F.
`
`SCF-SRF;
`
`SCF-SDF;
`
`G. SMF-SCF;
`
`H. SMF-SDF;
`
`I.
`
`J.
`
`SMF-SRF;
`
`SMF-SMAF;
`
`K. SMF-SCEF;
`
`L.
`
`SMF-SSF/CCF; and
`
`M. SSF-CCF.
`
`Five more functional relationships are related to network interworking, and they are introduced and discussed at the end
`of 7.
`
`Only the D, E and F relationships are covered by the CS-1 Recommendations.
`
`7.2
`
`Control classes
`
`The first six functional relationships of the above subclause (i.e., A, B, C, D, E, and F) require control capabilities. Four
`groupings of control capabilities, called control classes have been identified:
`
`1) Connection-control capabilities – the capabilities to establish, provide surveillance, and clear the bearer
`connections (e.g., voice paths through the network).
`
`2) Call-control (Non-IN Service-Control) capabilities – the capabilities to invoke the user and provide the
`end-to-end control required for the non-IN delivery of supplementary services. The non-IN delivery does
`not involve the structured separation of the CCF, SSF and SCF.
`
`3)
`
`IN service-control capabilities – the capabilities that involve the structured separation of the SSF from
`SCF.
`
`4) Management-related cont