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

1、I NTERNATIONAL TELECOMMUNICATION UN ITU-T TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU ON Q.1238.5 I SERIES Q: SWITCHING AND SIGNALLING Intelligent Network (0612000) IrAerface Recommendation for intelligent network capability set 3: SDF-SDF interface ITU-T Recommendation Q. 1238.5 (Formerly CCITT

2、 Recommendation) ITU-T Q-SERIES RECOMMENDATIONS SWITCHING AND SIGNALLING SIGNALLING IN THE INTERNATIONAL MANUAL SERVICE FUNCTIONS AND INFORMATION FLOWS FOR SERVICES IN THE ISDN SPECIFICATIONS OF SIGNALLING SYSTEMS No. 4 AND No. 5 SPECIFICATIONS OF SIGNALLING SYSTEM No. 6 SPECIFICATIONS OF SIGNALLING

3、 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 PUBLIC LAND MOBILE NETWORK INTERWORKING WITH SATELLITE MOBILE SYSTEMS INTELLIGENT NETWORK BROADBAND

4、 ISDN INTERNATIONAL AUTOMATIC AND SEMI-AUTOMATIC WORKING CLAUSES APPLICABLE TO ITU-T STANDARD SYSTEMS SIGNALLING REQUIREMENTS AND PROTOCOLS FOR IMT-2000 Q. 14.3 4.44.59 4.60-4.99 Q.lOO-Q.119 Q.12O-Q.249 Q.25O-Q.309 4.3104.399 Q.40O-Q.499 Q.50O-Q.599 Q.60O-Q.699 4.700-4.799 4.800-4.849 Q.85O-Q.999 Q.

5、 100O-Q. 1099 Q.110O-Q.1199 Q.120O-Q.1699 Q.170O-Q.1799 Q.200O-Q.2999 C Forfurther details, please refer to the list of ITU-T Recommendations. ITU-T Recommendation Q.1238.5 Interface Recommendation for intelligent network capability set 3: SDF-SDF interface Summary The Q.1238.x series of ITU-T Recom

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

7、 in ITU-T 4.123 1. Within the Q.123 series of IT-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. T

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

9、e description of the aspects of the SDF and SDF Functional Entities which are relevant to this interface. This Recommendation includes an electronic attachment containing clause 9 ASN. 1 definitions. Source ITU-T Recommendation 4.1238.5 was prepared by ITU-T Study Group 11 (1997-2000) and approved u

10、nder the WTSC Resolution 1 procedure on 15 June 2000. Keywords Intelligent Network (IN), Intelligent Network Application Protocol (INAP), IN Capability Set 3 (IN CS-3), Service Data Function (SDF) and SDF-SDF Interface. ITU-T 4.1238.5 (06/2000) i FOREWORD The International Telecommunication Union (I

11、TU) is the United Nations specialized agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. -T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardi

12、zing 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 turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is cove

13、red by the procedure laid down in WTSC Resolution 1. In some areas of information technology which fall within IT-Ts purview, the necessary standards are prepared on a collaborative basis with IS0 and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indica

14、te both a telecommunication administration and a recognized operating agency. INTELLECTLJAL PROPERTY RIGHTS ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning

15、 the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside 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

16、, which may be required to implement this Recommendation. However, implementors are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database. o rru 2001 All rights reserved. No part of this publication may be reproduced or utili

17、zed in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from ITU. ii ITU-T 4.1238.5 (06/2000) . CONTENTS Page 1 2 3 4 4.1 4.2 4.3 5 5.1 5.2 5.3 6 6.1 6.2 6.3 6.4 Scope . References . Abbreviations and acronyms Introduction . SDF-

18、SDF relationship . Introduction to the IN X.500 DSP and DISP Subset Versions and the niles for extensibility 4.3.1 Version negotiation 4.3.2 Initiating SDF side . Request processing at the responding SDF side 4.3.3 FSM for SDF Overview . SDME-FSM 5.2.1 State transition model for TFC Initiator relate

19、d states 5.2.2 SDF state transition model for SDF related states 5.3.1 SDF state transition models for shadowing . 5.3.2 SDF state transition models for chaining State transition model for TFC Respondor related states Detailed Operation Procedure . ChainedExecute procedure . 6.1.1 General descriptio

20、n 6.1.2 Parameters . 6.1.3 Invoking entity (SDF) IN-ChainedAddEntry procedure . 6.2.1 General description 6.2.3 Invoking entity (SDF) 6.2.4 Responding entity (SDF) . IN-ChainedModiQEntry procedure 6.3.1 General description 6.3.3 Invoking entity (SDF) 6.3.4 Responding entity (SDF) . 6.4.1 General des

21、cription 6.1.4 Responding entity (SDF) . 6.2.2 Parameters . 6.3.2 Parameters . IN-ChainedRemoveEntry procedure ITU-T Q.1238.5 (06/2000) 1 1 4 4 5 5 7 8 8 20 24 24 24 24 25 26 26 26 26 27 27 27 27 27 27 28 28 28 iii 6.5 6.6 6.7 6.8 6.9 6.10 6.1 1 iv 6.4.2 Parameters . 6.4.3 Invoking entity (SDF) IN-C

22、hainedSearch procedure 6.5.1 General description 6.5.3 Invoking entity (SDF) IN-CoordinateShadowUpdate procedure 6.6.1 General description 6.4.4 Responding entity (SDF) . 6.5.2 Parameters . 6.5.4 Responding entity (SDF) . 6.6.2 Parameters . 6.6.3 Supplier entity (SDF) . 6.6.4 Consumer entity (SDF) I

23、N-DSABind procedure 6.7.1 General description 6.7.2 Parameters . 6.7.3 Invoking Entity (SDF) . IN-DSAShadowBind procedure . 6.8.1 General description 6.8.3 Supplier entity (SDF) . IN-Requestshadowupdate procedure . 6.9.1 General description 6.9.2 Parameters . 6.9.3 Supplier entity (SDF) . 6.9.4 Cons

24、umer entity (SDF) IN-Unbind procedure 6.1 O . 1 General description 6.10.2 Parameters . 6.10.3 Inviting entity (SDF in shadowing) . 6.10.4 Responding entity (SDF in shadowing) . 6.10.5 Invoking entity (SDF in directory access) . 6.10.6 6.10.7 Invoking Entity (Initiating SDF in traffic flow control)

25、6.10.8 Responding Entity (Responding SDF in traffic flow control) . IN-Updateshadow procedure . 6.1 1.1 General description 6.7.4 Responding Entity (SDF) 6.8.2 Parameters . 6.8.4 Consumer entity (SDF) Responding entity (SDF in directory access) ITU-T 4.1238.5 (06/2000) Page 28 28 28 29 29 29 29 29 3

26、0 30 30 30 31 32 32 32 33 33 34 34 34 35 36 37 37 38 38 39 40 40 40 40 41 41 42 42 43 43 43 6.12 6.13 7 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 7.1 1 7.12 7.13 7.14 7.15 7.16 7.17 7.18 8 8.1 6.1 1.2 Parameters . 6.1 1.3 Supplier entity (SDF) . 6.11.4 Consumer entity (SDF) TFCBind procedure 6.12.1 G

27、eneral description 6.12.2 Invoking Entity (initiating SDF) 6.12.3 Responding Entity (responding SDF) TrafficFlowControl procedure 6.13.2 Parameters . 6.13.3 Invoking entity (Initiating SDF) 6.13.4 Responding entity (Responding SDF) Parameters . AgreementID 6.13.1 General description Argument Control

28、Type . : IN-Chainemgurnent . IN-ChainedResult . Information . LastUpdate Duration RequestedStrategy Result Security . SecurityParameters . TfcCntena . Updatedhfo Updatestrategy UpdateTime Updatewindow . Waschained Errors Operation related error procedures . 8.1.1 AttributeError 8.1.2 ExecutionError

29、. 8.1.3 IN-DirectoryBindError 8.1.4 IN-DSAReferral . ITU-T 4.1238.5 (06/2000) Page 43 44 45 46 46 46 47 47 47 47 48 48 49 49 49 49 49 49 51 51 52 52 52 52 52 52 52 53 53 53 53 54 54 54 55 56 56 V 9 10 10.1 10.2 10.3 10.4 Page 57 57 58 59 59 60 60 60 60 60 61 61 61 61 8.1.5 NameError . 8.1.6 Security

30、Error . 8.1.7 ServiceError . 8.1.8 ShadowError 8.1.9 TFCBindError 8.1.1 O UpdateError . ASN . 1 definitions (electronic attachment) . Normal procedures Abnormal procedures 10.3.1 Dialogue establishment 10.3.2 Dialogue ContinUation 10.3.3 Dialogue termination . Service assumed fiom TCAP Dialogue hand

31、ling . 10.3.4 User abort 10.3.5 Provider abort 10.3.6 Component handling . 10.4.1 Procedures for INAI? operations 10.4.2 Maming to TC comDonent Darameters . Mapping to TC dialogue primitives . 61 61 61 62 62 63 II Y A vi ITU-T 4.1238.5 (06/2000) ITU-T Recommendation 4.1238.5 Interface Recommendation

32、 for intelligent network capability set 3: SDF-SDF interface 1 Scope This Recommendation belongs to the Q.1238.x series of ITU-T Recommendations for IN Capability Set 3. It specifies the protocol on the SDF-SDF interface and provides a description of the aspects of the SDF and SDF Functional Entitie

33、s which are involved in the realization of this interface. 2 References All -T Recommendations and other references are identified in ITU-T Q. 1238.1. 3 Abbreviations and acronyms All abbreviations and acronyms used in this text are defined in -T 4.1238.1. 4 Introduction 4.1 SDF-SDF relationship Thi

34、s SDF-SDF relationship is used for messages between two SDFs in the public network. The relationship supports both access to service data, which can be for intra-network or inter-network purposes. The SDF-SDF relationship supports messages for services when no call is actually taking place (call unr

35、elated) as well as during call processing. For the most part, the call unrelated actions are to support the registration, authentication, encryption and handover procedures for terminal and personal mobility. The SDF-SDF relationship is also one of a limited set of relationships to support inter-net

36、working. As such it provides a point of interconnection to the network, effectively hiding the specific structure of the network and providing access security to the network from other public networks. The SDF-SDF relationship is used for various purposes. Each of the purposes can apply to the intra

37、-network, or inter-network cases. Specifically, the relationship is used for the following: a) Secured Data Acquisition: between SDFs. In this case a SDF requires data which is not stored within the SDF to complete a request for service data by another SDF. A crucial aspect of this relationship is s

38、ecurity necessary to support network isolation and internetworking. Secured Copying of Service Data: between SDFs. In this case a SDF copies a portion of service data which is controlled by another SDF. A crucial aspect of this relationship is the keeping of the original security and access informat

39、ion relation to the service data once the data has been copied and ensuring that copies of data are deleted when no longer required. b) 1 This Recommendation includes an electronic attachment containing clause 9 ASN. 1 definitions. ITU-T 4.1238.5 (06/2000) 1 4.2 The purpose of the SDF-SDF interface

40、is to allow the transfer of copies of service profiles fiom one SDF to another and to manage the copies within the database network. The X.500 functionalities cover more than the functionalities needed to fulfil the IN CS-3 requirements. This clause tries to indicate which aspects of the DSP and DIS

41、P should be considered and supported and which should be left out or ignored. Profiling is used as a means to present the status of the different parameters. It is important to mention that the number of parameters carried in a message should be minimized, to reduce the load on the signalling traffi

42、c and processing time. This is the reason why the parameters are removed unless they are absolutely necessary when they are sent. On reception removed parameters should not be treated but should be understood by the receiving entity. This allows the extension of the profile in the future according t

43、o its actual description in the 1997 edition of the Directory. For convenience and clarity this profile is defined using ASN.1 subtyping facilities however these defuitions do not form a protocol specification. This simply indicates which parameters an implementation should not send. It does not cha

44、nge the behaviour of the receiving entity which shall still be capable of decoding values which conform to the original definition of the DSP and DISP. Nevertheless elements that are excluded by subtyping should be understood but not treated. Several assumptions were used to design the DSP and DISP

45、for IN CS-3. They are as follows: Assumption 1: The agreements between network operators concerning the transfer of data are defined off-line (eg management operations). The establishOperationalBinding operation is only used to activate an agreement. Assumption 2: The agreements cannot be modified b

46、y an online operation. Assumption 3: The terminateperationalBinding operation is used to end an agreement between two network operators. This means that the copy held by the shadow-consumer is no longer maintained. It should not be used and should be deleted. However the agreement could be required

47、for future associations between the two networks, therefore this information should be retained. Assumption 4: The shadow updates are initiated by the shadow supplier who holds the master copy. Therefore modifications of the copies are not performed on the shadowed copies but only on the master copy

48、. The modification requests are passed to the master copy by using a chained operation. Copies are updated on changes, Assumption 5: Only direct references are used in DSAs. Operations can only be chained once. If the operation cannot be fulfilled after one chaining, a referral should be sent back.

49、Assumption 6: It is not possible to make a copy of a copy. One should refer to the master copy to get a copy. Assumption 7: The shadowing mechanism is initiated by a specific DAP operation or by a management operation. The management operation is for further study. Assumption 8: The time when a shadowing agreement is terminated depends on the type of service. In most cases it will be based on the number of copies. Once the maximum number of copies is reached for a part of a DIT, then the oldest copy has to be deleted and its agreement deactivated. The maximum number of copi