ITU-T Q 1238 3-2000 Interface Recommendation for Intelligent Network Capability Set 3 SCF-SRF Interface Series Q Switching and Signalling Intelligent Network (Study Group 11)《对于智能网.pdf

1、INTERNATIONAL TELECOMMUNICATION UN ION ITU=T TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Q.1238.3 SERIES Q: SWITCHING AND SIGNALLING Intelligent Network (06/2000) Interface Recommendation for intelligent network capability set 3: SCF-SRF interface ITU-T Recommendation Q.1238.3 (Formerly CCITT Re

2、commendation) ITU-T Q-SERIES RECOMMENDATIONS SWITCHING AND SIGNALLING SIGNALLING IN THE INTERNATIONAL MANUAL SERVICE FUNCTIONS AND INFORMATION FLOWS FOR SERVICES IN THE ISDN INTERNATIONAL AUTOMATIC AND SEMI-AUTOMATIC WORKING CLAUSES APPLICABLE TO ITU-T STANDARD SYSTEMS 1 SPECIFICATIONS OF SIGNALLING

3、 SYSTEMS No. 4 AND No. 5 SPECIFICATIONS OF SIGNALLING SYSTEM No. 6 SPECIFICATIONS OF SIGNALLING SYSTEM R1 SPECIFICATIONS OF SIGNALLING SYSTEM R2 DIGITAL EXCHANGES INTERWORKING OF SIGNALLING SYSTEMS SPECIFICATIONS OF SIGNALLING SYSTEM No. 7 43 INTERFACE DIGITAL SUBSCRIBER SIGNALLING SYSTEM No. 1 PUBL

4、IC LAND MOBILE NETWORK INTERWORKING WITH SATELLITE MOBILE SYSTEMS INTELLIGENT NETWORK BROADBAND ISDN SIGNALLING REQUIREMENTS AND PROTOCOLS FOR IMT-2000 Q. 14.3 4.4-4.59 Q.6O-Q.99 Q.lOO-Q.119 Q. 12-Q.249 Q.25O-Q.309 4.3 10.399 4.400-4.499 Q.50-Q.599 Q.60O-Q.699 4.700-4.799 4.800-4.849 4.850-4.999 Q.

5、1 OOO-Q. 1099 Q. 1 10O-Q. 1199 Q.120O-Q.1699 Q.17OO-Q.1799 Q.200O-Q.2999 For further details, please refer to the list of ITU-T Recommendations ITU-T Recommendation Q.1238.3 Interface Recommendation for intelligent network capability set 3: SCF-SRF interface Summary The Q. 1238.x series of ITU-T Rec

6、ommendations defines the Intelligent Network (IN) Application Protocol (INAP) for IN Capability Set 3 (IN CS-3), the INN for IN CS-3 based upon IN CS-2 4.1228 specification (1997) and the general rules for INN provided in ITU-T 4.1208, and is consistent with the scope of IN CS-3 as defined in ITU-T

7、Q. 123 1. Within the Q.123 series of ITU-T Recommendations, the Q.1238.x series describes the protocol realizing the 4.1231 Distributed Functional Plane in a service and vendor implementation independent manner, as constrained by the capabilities of the embedded base of network technology. This prov

8、ides the flexibility to allocate distributed functionality into multiple physical network configurations and to evolve IN from IN CS-3 to some future CS-N. This Recommendation belongs to the Q.1238.x series of ITU-T Recommendations for IN Capability Set 3. It covers the SCF-SRF interface including t

9、he description of the aspects of the SCF Functional Entity which are relevant to this interface. This Recommendation includes an electronic attachment containing clause 12 ASN. 1 definitions. Source ITU-T Recommendation 4.1238.3 was prepared by ITU-T Study Group 11 (1997-2000) and approved under the

10、 WTSC Resolution 1 procedure on 15 June 2000. Keywords CS-3, IN, INAP, IP, SCF, SRF. ITU-T Q.1238.3 (06/2000) 1 FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU-

11、T) is a permanent organ of ITU. 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

12、years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is covered by the procedure laid down in WTSC Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the n

13、ecessary standards are prepared on a collaborative basis with IS0 and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. INTELLECTUAL PROPERTY RIGHTS ITI draws attention to t

14、he possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside

15、of the Recommendation development process. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementors are cautioned that this may not represent the latest

16、 information and are therefore strongly urged to consult the TSB patent c) Resources. The SRF Resource Manager is contained in a block called Resource Control Pari along with the Resource Logic Library and the Resource Logic Instances; it is possible to split the Resources in the following blocks: a

17、) Resource Function Pari (RFP); b) Data Pari P). Enhancements of the SRF components are described in the following subclauses and in Figure 1. Functional Entity Access Manager (FEAM); 2 ITU-T 4.1238.3 (06/2000) SRF Resource Manager DatalBearer ControiSignaiiing I I Resource Logic Instances DP Data P

18、art FEAM Functionality Entity Access Manager RCP Resource Control Part RFP Resource Function Part SDSS Server Display and Scnpt Service J UI-scripts Figure UQ.1238.3 - SRF FE Model ? ITU-T 4.1238.3 (06/2000) F E A M 3 RFP DP announcem. DB manager voice record. recorded v. voice recog. sound DTMF coi

19、lec./detect image Modem detec. SDSS Text To Speech text SSF/CCF OSF SCF 6.1 Resource Control Part (RCP) The RCP contains SRF service logic, and controls the service procedure using the capabilities of other blocks. To offer a specialized resource, RCP uses resource-function pair in the RFP and data

20、in the DP. Whenever RCP receives a call requesting a specialized resource-function pair, it invokes the internal resource controller, which manages the first needed resource function pair to make a decision of admission or rejection of the call. The SRF sends ACK or NACK messages according to the de

21、cision by the resource controller. There are as many controllers as there are special resource function types. The controllers accept or reject calls requesting a resource-function pair on the basis of characteristic parameters. A controller consists of an interface unit and a decision unit. First o

22、ne encodes and decodes messages fromto the FEAM, and makes the input patterns for the decision unit; the characteristic parameter permitting the acceptation or rejection of the call controlled by an algorithm within the decision unit, and is based on the parameters from the interface unit. 6.1.1 SRF

23、 Resource Manager The RM provides the functionality which is necessary for the SRF to manage the resources contained in it. The RM contains the capabilities to search for a resource, to allocate or de-allocate it, to manage the status of a resource, and to control its actions. 6.1.2 Transaction Modu

24、le The Transaction Module provides the functionality necessary for: - - detection of transactions from the communication links; routing of transactions to the right applications scripts. 6.1.3 User Interaction-scripts (UI-Script) It provides to the SCF a vision of the different specialized resources

25、 functions that the SRF can perform. A User Interaction-script is an aggregation of Resource Function. 6.1.4 Resource Logic Library It indicates the SRF Logic and Physic Resources that are necessary for a given User Interaction-script . 6.1.5 Resource Logic Instances It instances the SRF resources t

26、hat are necessary for the correct execution of the invoked specialized resource. 6.2 Resource Function Part (RFP) The RFP is a collection of resource-function pairs or functional elements of resources. Resources in a resource-function pair for a service procedure, are allocated and released together

27、. 6.3 Data Part P) The DP is composed of a database manager and a database containing recorded voice, sound, image, text, etc. 4 ITU-T 4.1238.3 (06/2000) 7 SRF application entity procedures As described in ITU-T Q. 1238.1, the SRF FSM handles interactions with the SSF FSM and the SCF FSM entity. The

28、 SRME-control interfaces to the various SRF call state models (SRSM) and the functional entity access manager (FEAM). The SRF FSM structure is described in Figure2. The FEAM is described in ITU-T Q. 1238.1. General tasks of the SRME-control are defined in ITU-T 4.1238.1. In addition to the general t

29、asks, the SRME-control checks the existence of a SCF-SRF relationship by receiving an Activitytest operation from the SCF and returns the result to the SCF. SMF SCF SRME-Control SRF TI 1 I 74- Figure 2/Q.1238.3 - SRF-FSM Structure The SRSM and SRME-FSM are described in the following clauses. 7.1 The

30、 SRME handles the following operation: - sRFCallGap The SRF management finite state model (SRME FSM) The sRFCallGap operation is issued within a context of an existing relationship and does not cause state transitions in the SRME. All other operations have no effect on the SRME-FSMs; the operations

31、are passed by the SRME-Control to the relevant FSM. 7.2 The SRSM is presented in Figure 3. In what follows, each state is described in a separate clause together with the events that cause a transition out of this state. Finally, the outputs are presented within smaller rectangles than the states ar

32、e; unlike the states and events, the outputs are not enumerated. Each state is discussed in the following subclauses. General rules applicable to more than one state are addressed here. The SRF call State Model: SRSM ITU-T 4.1238.3 (06/2000) 5 Received messages may include a single operation or mult

33、iple operations, and it is processed as follows: - The SRSM processes the operations in the order in which they are received. The SRSM examines subsequent operations in the sequence. When a Cancel (for Playhouncement, PromptAndCollectUserInformation or PromptAndReceiveMessage) operation is encounter

34、ed in the sequence in state “user interaction“, it executes it immediately. In all other cases, the SRSM queues the operations. and awaits an event (such an event would be the completion of the operation being executed, or reception of an external event). If there is an error in processing one of th

35、e operations in the sequence, the SRF FSM processes the error (see below) and discards all remaining operations in the sequence. If an operation is not understood or is out of context (i.e. it violates the SACF rules defined by the SRSM) as described above, the SRF FSM processes the error according

36、to the rules given in ITU-T 4.1238.1 (using TC-U-REJECT or the operation error UnexpectedComponent Sequence). In any state, if there is an error in a received operation, the maintenance functions are informed. Generally, the SRSM remains in the same state in which it received the erroneous operation

37、s, however different error treatments are possible in specific cases as described in ITU-T 4.1238.1; depending on the class of the operation, the error could be reported by the SRF to the SCF using the appropriate component (see ITU-T 4.774). In any state, if the dialogue with the SCF (direct SCF-SR

38、F case) is terminated, then the SRSM returns to idle state after ensuring that all resources allocated to the dialogue have been de-allocated. The SRF shall remain connected to the SSF as long as it has Playhouncement operations active or buffered. Depending on the type of script, the SRF may also r

39、emain connected when a script is active or when a ScriptRu is buffered. The resources allocated to the call will be de-allocated when all announcements are completed or when the SSF disconnects the bearer connection (i.e. call party release). In any state (except “idle“), if the SSF disconnects the

40、bearer connection to the SRF before the SRF completes the user interaction, then the SRSM clears the call and ensures that all SRF resources allocated to the call have been de-allocated. Then it transits to the “idle“ state. - The SRSM has an application timer, TSW, whose purpose is to prevent exces

41、sive unnecessary resource allocation. This timer is set when the SRF sends Setup Response bearer message to the SSF (SSF relay case) or the AssistRequestInsctions operation (Direct SCF-SRF case). This timer is stopped when a request is received from the SCF. The SRF may reset TSW on transmission of

42、the SpecializedResourceReport, ScriptEvent and ScriptClose operation, the return result for the PromptAndCollectUserInformation operation or the return result for the PromptAndReceiveMessage operation when there is no queued user interaction operation. On the expiration of Ts, the SRSM transits to t

43、he “idle“ state ensuring that all SRF resources allocated to the call have been de-allocated. 6 ITU-T 4.1238.3 (06/2000) (El) Connect-Request- from-SSF I I l I I L - Disconnect-Bearer- Connection 2. Connected F interaction (E2) Instruction-fiom-SCF (E13) ScriptRun-fiom-SCF (e4) SRF-Sani-Timeout (E3)

44、 Connection-Releas- from-SSF I Instructions (E 1 O) Connection-Released- from-SSF (El 8) Instruction-from-SCF (E6) Cancel-Yom-SCF (e7) SRF_Report-to-SCF (es) PlayAnnouncemenPromptAnd CollectUserInformatiod PromptAndReceiveMessage-Cancelled-to-SCF (e9) Cancel-Error-to-SCF (el 5) ScnptEvent-to-SCF (E

45、16) ScriptInformation-from-SCF (E17) ScriptRm-from-SCF Figure 3/Q.1238.3 - The SRSM 7.2.1 State 1: “Idle“ The “idle“ state represents the condition prior to, or at the completion of, an instance of user interaction. This state is entered as a result of events E3, e4, Elo, el 1 and e12. - (E3) Connec

46、tion-Released-fm-SSF: This event takes place when the SRSM receives a release message from the SSF in connected state. The SRSM goes to state “Idle“. (e4) SRF - Sanity-Timeout: This event occurs when the SRSM has been in connected state for a network-operator-defined period of time (timer TSW) witho

47、ut having an SCF initiated operation to execute. The SRF initiates a bearer channel disconnect sequence to the SSF using the applicable bearer channel signalling system. The SRSM goes to state “Idle“. - ITU-T 4.1238.3 (06/2000) 7 - (Elo) Connection-Released-from-SSF: This event takes place when the

48、SRSM receives a release message from the SSF in “user interaction“ state. The SRSM goes to state “Idle“. (ell) Disconnect-to-SSF: This event occurs when the SCF has enabled SRF initiated disconnect by: the last Playhouncement PromptAndCollectUserInformatiod - PromptAndReceiveMessage/ScriptRun from S

49、CF (E2) or (E 1 8) with the parameter disconnectFromIPForbidden. The SRSM initiates a bearer channel disconnect sequence to the SSF using the applicable bearer channel signalling system after sending the last SpecializedResourceRepodScriptEvent operation to the SCF (e7). The SRSM goes to state Ydle“; or by a parameter in the ScriptRun operation. (e12) SRF-Sanity-Timeout: This event occurs when the SRSM has been in User interaction state for a network-operator-defined period of time (timer Ts) without having an SCF initiated operation to execute. The SRF initiates a bearer c