INTERNATIONAL TELECOMMUNICATION UNION
`
`)45 4
`
`TELECOMMUNICATION
`STANDARDIZATION SECTOR
`OF ITU
`
`1(cid:14)(cid:17)(cid:18)(cid:17)(cid:21)
`
`(10/95)
`
`).4%,,)’%.4.%47/2+
`
`0(93)#!,0,!.%&/2).4%,,)’%.4
`.%47/2+#3 (cid:17)
`
`)45 42ECOMMENDATION1(cid:14)(cid:17)(cid:18)(cid:17)(cid:21)
`
`(Previously “CCITT Recommendation”)
`
`Bright House Networks - Ex. 1021, Page 1
`
`

`
`FOREWORD
`
`The ITU-T (Telecommunication Standardization Sector) is a permanent organ of the International Telecommunication
`Union (ITU). The ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommen-
`dations on them with a view to standardizing telecommunications on a worldwide basis.
`
`The World Telecommunication Standardization Conference (WTSC), which meets every four years, establishes the
`topics for study by the ITU-T Study Groups which, in their turn, produce Recommendations on these topics.
`
`The approval of Recommendations by the Members of the ITU-T is covered by the procedure laid down in WTSC
`Resolution No. 1 (Helsinki, March 1-12, 1993).
`
`ITU-T Recommendation Q.1215 was revised by ITU-T Study Group 11 (1993-1996) and was approved under the
`WTSC Resolution No. 1 procedure on the 17th of October 1995.
`
`___________________
`
`In this Recommendation, the expression “Administration” is used for conciseness to indicate both a telecommunication
`administration and a recognized operating agency.
`
`NOTE
`
`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 1996
`
`Bright House Networks - Ex. 1021, Page 2
`
`

`
`Recommendation Q.1215 (10/95)
`
`CONTENTS
`
`SUMMARY ..............................................................................................................................................................
`1
`General ...........................................................................................................................................................
`2
`Requirements and assumptions ......................................................................................................................
`2.1
`Requirements ....................................................................................................................................
`2.2
`Assumptions .....................................................................................................................................
`Physical Entities (PEs) ...................................................................................................................................
`Mapping requirements....................................................................................................................................
`Mapping the distributed functional plane to the physical plane.....................................................................
`5.1
`Mapping of functional entities to physical entities ...........................................................................
`5.2
`Mapping of FE-FE relationships to PE-PE relationships .................................................................
`5.3
`Selection of underlying protocol platforms ......................................................................................
`
`3
`4
`5
`
`Page
`ii
`1
`1
`1
`1
`2
`3
`4
`4
`6
`6
`
`Recommendation Q.1215 (10/95)
`
`i
`
`Bright House Networks - Ex. 1021, Page 3
`
`

`
`SUMMARY
`
`This Recommendation describes the physical plane of the IN architecture for CS-1. The physical plane identifies
`different Physical Entities (PEs), the allocation of functional entities to PEs, and the interfaces between the PEs.
`
`The status of the text in this Recommendation is stable and there are no outstanding issues identified for further study.
`
`Companion Recommendations include the Q.1200- and Q.1210-Series of Recommendations, especially that of
`Recommendation Q.1205, which describes the physical plane for general IN. The revisions that appear in the current text
`of this Recommendation were applied to make it consistent with the companion Recommendations.
`
`ii
`
`Recommendation Q.1215 (10/95)
`
`Bright House Networks - Ex. 1021, Page 4
`
`

`
`Recommendation Q.1215
`
`Recommendation Q.1215 (10/95)
`
`PHYSICAL PLANE FOR INTELLIGENT NETWORK CS-1
`
`(Helsinki, 1993; revised in 1995)
`
`1
`
`General
`
`This Recommendation describes the physical plane of the IN architecture for CS-1. General IN physical plane informa-
`tion is contained in Recommendation Q.1205.
`
`The physical plane of the IN conceptual model identifies the different physical entities and the interfaces between these
`entities.
`
`The physical plane architecture should be consistent with the IN conceptual model. The IN conceptual model is a tool
`that can be used to design the IN architecture to meet the following main objectives:
`
`–
`
`–
`
`–
`
`service implementation independence;
`
`network implementation independence;
`
`vendor and technology independence.
`
`The I.130 stage 3 service description methodology may be used (which includes the functional specification of the node
`and detailed description of the protocol between the nodes) in developing the physical plane architecture.
`
`2
`
`Requirements and assumptions
`
`2.1
`
`Requirements
`
`The key requirements of the physical plane architecture are:
`
`–
`
`–
`
`–
`
`–
`
`–
`
`–
`
`–
`
`–
`
`the functional entities in the CS-1 distributed functional plane can be mapped onto the CS-1 physical
`entities;
`
`one or more functional entities may be mapped onto the same physical entity;
`
`one functional entity cannot be split between two physical entities (i.e. the functional entity is mapped
`entirely within a single physical entity);
`
`duplicate instances of a functional entity can be mapped to different physical entities, though not to the
`same physical entity;
`
`physical entities can be grouped to form a physical architecture;
`
`the physical entities may offer standard interfaces;
`
`vendors must be able to develop physical entities based on the mapping of functional entities and the
`standard interfaces;
`
`vendors must be able to support mature technologies and new technologies as they become available.
`
`2.2
`
`Assumptions
`
`The following assumptions are made for the development of the physical plane architecture:
`
`–
`
`–
`
`the IN conceptual model is used as a tool to develop the IN physical architecture;
`
`existing and new technologies can be used to develop the physical entities;
`
`Recommendation Q.1215 (10/95)
`
`1
`
`Bright House Networks - Ex. 1021, Page 5
`
`

`
`–
`
`–
`
`the specification of functional entities in the distributed functional plane and standard interfaces in the
`physical plane will make the network vendor independent and service independent;
`
`for CS-1, a sufficient number of interfaces will be identified for support of services. Service creation and
`OAM functions will not be addressed.
`
`3
`
`Physical Entities (PEs)
`
`This clause describes a selection of PEs to support IN CS-1. That selection is not intended to preclude or disallow the
`application of any other IN PE to support CS-1.
`
`a)
`
`Service Switching Point (SSP)
`
`In addition to providing users with access to the network (if the SSP is a local exchange) and performing
`any necessary switching functionality, the SSP allows access to the set of IN capabilities. The SSP
`contains detection capability to detect requests for IN-based services. It also contains capabilities to
`communicate with other PE(s) containing a Service Control Function (SCF), such as a Service Control
`Point (SCP), and to respond to instructions from the other PE. Functionally, an SSP contains a Call
`Control Function (CCF), a Service Switching Function (SSF), and, if the SSP is a local exchange, a Call
`Control Agent Function (CCAF). It also may optionally contain a Service Control Function (SCF), and/or
`a Specialized Resource Function (SRF), and/or a Service Data Function (SDF). The SSP may provide
`IN-based services to users connected to subtending Network Access Points.
`
`b) Network Access Point (NAP)
`
`An NAP is a PE that includes only the CCAF and CCF functional entities. It may also be present in the
`network. The NAP supports early and ubiquitous deployment of IN-based services. This NAP cannot
`communicate with an SCF, but it has the ability to determine when IN processing is required. It must send
`calls requiring IN processing to an SSP.
`
`c)
`
`Service Control Point (SCP)
`
`The SCP contains the Service Logic Programs (SLPs) and data that are used to provide IN-based services.
`The SCP is connected to SSPs by a signalling network. Multiple SCPs may contain the same SLPs and
`data to improve service reliability and to facilitate load sharing between SCPs. Functionally, an SCP
`contains a Service Control Function (SCF) and a Service Data Function (SDF). The SCP can access data
`in an SDP either directly or through a signalling network. The SDP may be in the same network as the
`SCP, or in another network. The SCP can be connected to SSPs, and optionally to IPs, through the
`signalling network. The SCP can also be connected to an IP via an SSP relay function.
`
`d) Adjunct (AD)
`
`The Adjunct PE is functionally equivalent to an SCP (i.e. it contains the same functional entities) but it is
`directly connected to an SSP. Communication between an Adjunct and an SSP is supported by a high
`speed interface. This arrangement may result in differing performance characteristics for an Adjunct and
`an SCP. The application layer messages are identical in content to those carried by the signalling network
`to an SCP.
`
`An Adjunct may be connected to more than one SSP and an SSP may be connected to more than one
`Adjunct.
`
`2
`
`Recommendation Q.1215 (10/95)
`
`Bright House Networks - Ex. 1021, Page 6
`
`

`
`e)
`
`Intelligent Peripheral (IP)
`
`The IP provides resources such as customized and concatenated voice announcements, voice recognition,
`and Dual Tone Multi-Frequencies (DTMF) digit collection, and contains switching matrix to connect
`users to these resources. The IP supports flexible information interactions between a user and the
`network. Functionally, the IP contains the Specialized Resource Function (SRF). The IP may directly
`connect to one or more SSPs, and/or may connect to the signalling network.
`
`An SCP or Adjunct can request an SSP to connect a user to a resource located in an IP that is connected to
`the SSP from which the service request is detected. An SCP or Adjunct can also request the SSP to
`connect a user to a resource located in an IP that is connected to another SSP.
`
`f)
`
`Service Node (SN)
`
`The SN can control IN-based services and engage in flexible information interactions with users. The SN
`communicates directly with one or more SSPs, each with a point-to-point signalling and transport
`connection. Functionally, the SN contains an SCF, SDF, SRF, and an SSF/CCF. This SSF/CCF is closely
`coupled to the SCF within the SN, and is not accessible by external SCFs.
`
`In a manner similar to an Adjunct, the SCF in an SN receives messages from the SSP, executes SLPs, and
`sends messages to the SSP. SLPs in an SN may be developed by the same service creation environment
`used to develop SLPs for SCPs and Adjuncts. The SRF in an SN enables the SN to interact with users in a
`manner similar to an IP. An SCF can request the SSF to connect a user to a resource located in an SN that
`is connected to the SSP from which the service request is detected. An SCF can also request the SSP to
`connect a user to a resource located in an SN that is connected to another SSP.
`
`g)
`
`Service Switching and Control Point (SSCP)
`
`The SSCP is a combined SCP and SSP in a single node. Functionally, it contains an SCF, SDF, CCAF,
`CCF and SSF. The connection between the SCF/SDF functions and the CCAF/CCF/SSF functions is
`proprietary and closely coupled, but it provides the same service capability as an SSP and SCP separately.
`
`This node may also contain SRF functional capabilities (i.e. SRF as an optional capability).
`
`The interfaces between the SSCP and other PEs are the same as the interfaces between the SSP and other
`PEs, and therefore will not be explicitly stated.
`
`h)
`
`Service Data Point (SDP)
`
`The SDP contains the customer and network data which is accessed during the execution of a service.
`Functionally, the SDP contains an SDF.
`
`4
`
`Mapping requirements
`
`–
`
`–
`
`–
`
`–
`
`physical plane architecture requirements listed in 2.1 should be met;
`
`functional entities should be mapped to physical entities in a manner which will support the identified
`benchmark CS-1 services;
`
`functional entity to physical entity mapping must allow efficient implementation in existing physical
`entities;
`
`functional entity to physical entity mapping must allow for standard communications between network
`functions via service independent interfaces.
`
`Recommendation Q.1215 (10/95)
`
`3
`
`Bright House Networks - Ex. 1021, Page 7
`
`

`
`5
`
`Mapping the distributed functional plane to the physical plane
`
`5.1
`
`Mapping of functional entities to physical entities
`
`This subclause gives a mapping of functional entities into physical entities for CS-1, and describes the reference points
`between the PEs. In so doing, an appropriate distribution of functionality for CS-1 is identified, and functional interfaces
`suitable for standardization are highlighted. The PEs described in this subclause are for illustrative purposes only, and do
`not imply the only possible mapping of functionality for CS-1.
`
`This subclause describes a flexible physical architecture made up of several PEs. Each PE contains one or more
`functional entities, which define its IN functionality. PEs included in the physical architecture shown in Figure 1 are
`Service Switching Point (SSP), Network Access Point (NAP), Service Control Point (SCP), Intelligent Peripheral (IP),
`Adjunct (AD), Service Switching and Control Point (SSCP), Service Data Point (SDP), and Service Node (SN).
`
`Typical scenarios of functional entity mapping to physical entity are shown in Table 1.
`
`TABLE 1/Q.1215
`
`Typical scenarios of FE to PE mapping
`
`PEs
`
`SSP
`
`SCP
`
`SDP
`
`IP
`
`AD
`
`SN
`
`SSCP
`
`NAP
`
`FEs
`
`SCF
`
`SSF/CCF
`
`SDF
`
`SRF
`
`O
`
`C
`
`–
`
`–
`
`C
`
`C
`
`C
`
`–
`
`C
`
`–
`
`–
`
`–
`
`–
`
`C
`
`C
`
`C
`(CCF only)
`
`O
`
`C
`
`C
`
`–
`
`C
`
`C
`
`C
`
`–
`
`O
`
`–
`
`–
`
`C
`
`–
`
`C
`
`O
`
`–
`
`C
`O
`–
`
`Core
`Optional
`Not allowed
`
`There is no intention that the table should disallow any other combination of functional entities that would result in a PE
`not shown in the table.
`
`The above mappings are shown in Figure 1. Each PE has certain functional entities mapped into it. The solid lines on the
`figure show transport paths that may exist between the PEs, and the dotted lines show signalling paths that can carry
`application layer messages for IN-based services.
`
`4
`
`Recommendation Q.1215 (10/95)
`
`Bright House Networks - Ex. 1021, Page 8
`
`

`
`Interfaces:
`SCP-SSP
`AD-SSP
`IP-SSP
`SN-SSP
`SCP-IP
`AD-IP
`SCP-SDP
`
`SRF
`
`IP
`
`SSF
`
`CCF
`
`SN
`
`SCF
`
`SDF
`
`SRF
`
`a) An SSCP PE additionally includes the
`SCF and SDF FEs as core elements.
`
`Transport
`
`Signalling
`
`Optional FE
`
`Physical entities (PEs)
`AD
`Adjunct
`IP
`Intelligent Peripheral
`SSP
`Service Switching Point
`SCP
`Service Control Point
`SN
`Services Node
`NAP
`Network Access Point
`SDP
`Service Data Point
`SSCP
`Service Switching and Control Point
`
`Functional entities (FEs)
`Call Control Function
`CCF
`Call Control Agent Function
`CCAF
`Service Control Function
`SCF
`Service Data Function
`SDF
`Special Resource Function
`SRF
`Service Switching Function
`SSF
`
`FIGURE 1/Q.1215...[D01] =
`
`SCF
`
`SDF
`
`SCP
`
`SS No. 7 Network
`
`a)
`
`SCF
`
`SRF
`
`SSP
`
`CCF
`
`SSF
`
`SDF
`
`SDP
`
`To other SCPs and/or
`SDPs in this or
`another network
`
`SCF
`
`SDF
`
`CCF
`
`AD
`
`NAP
`
`a)
`
`SDF
`
`CCAF
`
`CCAF
`
`T1143320-92/d01
`
`FIGURE 1/Q.1215
`Scenarios for physical architectures
`
`Recommendation Q.1215 (10/95)
`
`5
`
`Bright House Networks - Ex. 1021, Page 9
`
`

`
`5.2
`
`Mapping of FE-FE relationships to PE-PE relationships
`
`The FE-FE interfaces that fall within the scope of CS-1 are:
`
`1)
`
`2)
`
`3)
`
`SSF-SCF;
`
`SCF-SDF; and
`
`SCF-SRF.
`
`A mapping to the PE-PE interfaces is provided in Table 2.
`
`Table 2 is not meant to be an exhaustive list of all possible PE-PE relationships that may be covered by the CS-1
`Recommendations.
`
`TABLE 2/Q.1215
`
`FE-FE relationships to PE-PE relationships
`
`FE-FE
`
`SSF-SCF
`
`SCF-SDF
`
`SCF-SRF
`
`PE-PE
`
`SSP-SCP
`
`SSP-AD
`
`SSP-SN
`
`SSP-SCP
`
`SCP-SDP
`
`SCP-IP
`
`SCP-SSP-IP
`
`AD-IP
`
`5.3
`
`Selection of underlying protocol platforms
`
`This subclause describes the candidate interfaces for CS-1 between the elements of the physical architecture. The
`interfaces are identified below.
`
`–
`
`–
`
`–
`
`–
`
`–
`
`–
`
`–
`
`SCP-SSP;
`
`AD-SSP;
`
`IP-SSP;
`
`SN-SSP;
`
`SCP-IP;
`
`AD-IP; and
`
`SCP-SDP.
`
`Existing lower-layer protocols are proposed for these candidate interfaces to carry the application layer messages
`required by IN-based services. As such, the focus of the standardization effort for CS-1 is on the application layer
`protocols. At the application layer, the message sent that the different interfaces carry should reflect the same semantic
`content, even though the application layer messages may be encoded or formatted differently. For example, the messages
`between the SSF in an SSP and the SCF in an SCP, Adjunct or SN should contain the same information. The following
`subclauses give some proposed protocols for use on these interfaces.
`
`6
`
`Recommendation Q.1215 (10/95)
`
`Bright House Networks - Ex. 1021, Page 10
`
`

`
`5.3.1
`
`SCP-SSP interface
`
`The proposed underlying protocol platform for the interface between an SCP and an SSP is Transaction Capabilities
`Application Part (TCAP) on Signalling Connection Control Part (SCCP)/Message Transfer Part (MTP) of SS No. 7.
`
`5.3.2
`
`AD-SSP interface
`
`The proposed underlying protocol platform for the AD-SSP interface is TCAP. The physical interface has not been
`specified, but a number of alternative standard protocols could be used.
`
`5.3.3
`
`IP-SSP interface
`
`This interface is used for communications between an IP and an SSP as well as for communication between an IP and an
`SCP which is being relayed through an SSP.
`
`The proposed underlying protocol platform for the interface between an IP and an SSP is ISDN Basic Rate Interface
`(BRI), Primary Rate Interface (PRI) (or both), or SS No. 7.
`
`If a BRI or PRI is used, the ISDN D-channel connecting an IP to an SSP carries application layer information between
`an SCF and an SRF, and supports the setup of B-channel connections to the IP. Information passed from an SCF to an
`SRF (e.g. announcement number and number of digits to collect) and vice versa (e.g. collected information and billing
`measurements) is embedded in the facility information element. The facility information element can be carried by some
`Q.931 messages, such as SETUP and DISCONNECT. The facility information element can also be carried by the
`FACILITY message of Recommendation Q.931. This possibility provides for the flexibility to convey application layer
`information without affecting the call connection establishment.
`
`5.3.4
`
`SN-SSP interface
`
`The proposed underlying protocol platform for the interface between an SN and an SSP is ISDN Basic Rate Interface
`(BRI), Primary Rate Interface (PRI) (or both). An SN and an SSP exchange application layer messages over an ISDN
`D-channel using the common element procedures of Recommendation Q.932. This communication may occur on a
`separate D-channel from the channel that carries the common element procedure messages. Figure 1 shows the case
`where these channels are separate.
`
`5.3.5
`
`SCP-IP interface
`
`The proposed underlying protocol platform for an interface between an SCP and an IP is Transaction Capabilities
`Application Part (TCAP) on Signalling Connection Control Part (SCCP)/MTP of SS No. 7.
`
`5.3.6
`
`AD-IP interface
`
`The proposed underlying protocol platform between an AD and an IP is TCAP. The physical interface has not been
`specified, but a number of alternative standard protocols could be used.
`
`5.3.7
`
`SCP-SDP interface
`
`The proposed underlying protocol platform for the interface between an SCP and an SDP is Transaction Capabilities
`Application Part (TCAP) in Signalling Connection Control Part (SCCP)/MTP of SS No. 7. For SDPs outside the
`network (e.g. credit card validation database at credit card company), an interworking unit can be used which is inside
`the network and performs translation of SS No. 7 TCAP to a public or private data transfer protocol (e.g. Recommen-
`dation X.25).
`
`5.3.8
`
`User interfaces
`
`A user is an entity external to the IN that uses IN capabilities. IN users may employ the access interfaces described
`below to invoke various IN service capabilities. For example, users can affect the routing of a call, send and receive
`information from the network, screen calls, and update service parameters. Users are served by existing network
`interfaces.
`
`Recommendation Q.1215 (10/95)
`
`7
`
`Bright House Networks - Ex. 1021, Page 11
`
`

`
`It is important to ensure that IN should continue to support existing services and capabilities. In addition, the current
`restrictions imposed by each of the interface technologies described below must be considered when deploying IN-based
`services. For example, calling party information may or may not be available at a given interface and, therefore, may or
`may not be provided to the SCF.
`
`End users use analogue interface signalling, or ISDN access signalling arrangements. IN user-network interactions
`include providing stimuli, such as off-hook or DTMF digit signalling, which determine further IN action.
`
`Out-of-band (i.e. D-channel) signalling provides ISDN users with additional capabilities for accessing potential
`IN-based services. When originating a call, an ISDN user identifies the bearer capability to be associated with the call.
`IN service logic can use this information to determine how the call should be handled (e.g. how to route the call).
`
`8
`
`Recommendation Q.1215 (10/95)
`
`Bright House Networks - Ex. 1021, Page 12