1、 INTERNATIONAL TELECOMMUNICATION UNION ITU-T Q.1248.5 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (07/2001) SERIES Q: SWITCHING AND SIGNALLING Intelligent Network Interface Recommendation for Intelligent Network Capability Set 4: SDF-SDF interface ITU-T Recommendation Q.1248.5 ITU-T Q-SERIES REC
2、OMMENDATIONS SWITCHING AND SIGNALLING SIGNALLING IN THE INTERNATIONAL MANUAL SERVICE Q.1Q.3 INTERNATIONAL AUTOMATIC AND SEMI-AUTOMATIC WORKING Q.4Q.59 FUNCTIONS AND INFORMATION FLOWS FOR SERVICES IN THE ISDN Q.60Q.99 CLAUSES APPLICABLE TO ITU-T STANDARD SYSTEMS Q.100Q.119 SPECIFICATIONS OF SIGNALLIN
3、G SYSTEMS No. 4 AND No. 5 Q.120Q.249 SPECIFICATIONS OF SIGNALLING SYSTEM No. 6 Q.250Q.309 SPECIFICATIONS OF SIGNALLING SYSTEM R1 Q.310Q.399 SPECIFICATIONS OF SIGNALLING SYSTEM R2 Q.400Q.499 DIGITAL EXCHANGES Q.500Q.599 INTERWORKING OF SIGNALLING SYSTEMS Q.600Q.699 SPECIFICATIONS OF SIGNALLING SYSTEM
4、 No. 7 Q.700Q.799 Q3 INTERFACE Q.800Q.849 DIGITAL SUBSCRIBER SIGNALLING SYSTEM No. 1 Q.850Q.999 PUBLIC LAND MOBILE NETWORK Q.1000Q.1099 INTERWORKING WITH SATELLITE MOBILE SYSTEMS Q.1100Q.1199 INTELLIGENT NETWORK Q.1200Q.1699 SIGNALLING REQUIREMENTS AND PROTOCOLS FOR IMT-2000 Q.1700Q.1799 SPECIFICATI
5、ONS OF SIGNALLING RELATED TO BEARER INDEPENDENT CALL CONTROL (BICC) Q.1900Q.1999 BROADBAND ISDN Q.2000Q.2999 For further details, please refer to the list of ITU-T Recommendations. ITU-T Rec. Q.1248.5 (07/2001) i ITU-T Recommendation Q.1248.5 Interface Recommendation for Intelligent Network Capabili
6、ty Set 4: SDF-SDF interface Summary The Q.1248.x family of ITU-T Recommendations defines the Intelligent Network (IN) Application Protocol (INAP) for IN Capability Set 4 (IN CS-4). This definition is based upon IN CS-3 ITU-T Q.1238 and ITU-T Q.1234 (2000) and upon the general rules for INAP provided
7、 in ITU-T Q.1208, and is consistent with the scope of IN CS-4 as defined in ITU-T Q.1241. Within the Q.124x series of ITU-T Recommendations, the Q.1248.x family of ITU-T Recommendation describes the protocol realizing the Q.1241 Distributed Functional Plane in a service and vendor implementation ind
8、ependent manner, as constrained by the capabilities of the embedded base of network technology. This provides the flexibility to allocate distributed functionality into multiple physical network configurations and to evolve IN from IN CS-4 to some future IN CS-N. This Recommendation belongs to the Q
9、.1248.x family of ITU-T Recommendations for IN CS-4. It covers the SDF-SDF interface including the description of the aspects of the SDF and SDF Functional Entities which are relevant to this interface. This Recommendation includes an electronic attachment containing Annex A, ASN.1 definitions. Sour
10、ce ITU-T Recommendation Q.1248.5 was prepared by ITU-T Study Group 11 (2001-2004) and approved under the WTSC Resolution 1 procedure on 13 July 2001. Keywords Intelligent Network (IN), Intelligent Network Application Protocol (INAP), IN Capability Set 4 (IN CS-4), Service Data Function (SDF), SDF-SD
11、F Interface. ii ITU-T Rec. Q.1248.5 (07/2001) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying
12、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, establishes the topics for study by the ITU-T study groups
13、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 necessary standards are prepared on a collaborative basis with ISO
14、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 ITU draws attention to the possibility that the practice or implementation of this Recomme
15、ndation 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 of the Recommendation development process. As of the date of appro
16、val 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 information and are therefore strongly urged to consult the TSB p
17、atent database. ITU 2002 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 ITU. ITU-T Rec. Q.1248.5 (07/2001) iii CONTENTS Page 1 Scope. 1 2 Re
18、ferences. 1 3 Abbreviations and acronyms 1 4 Introduction. 1 4.1 SDF-SDF relationship. 1 4.2 Introduction to the IN X.500 DSP and DISP subset. 2 4.3 Versions and the rules for extensibility 3 4.3.1 Version negotiation 3 4.3.2 Initiating SDF side. 3 4.3.3 Request processing at the responding SDF side
19、. 4 5 FSM for SDF 4 5.1 Overview. 4 5.2 SDME-FSM 6 5.2.1 State transition model for TFC Initiator-related states 6 5.2.2 State transition model for TFC Responder-related states 7 5.3 SDF state transition model for SDF-related states 9 5.3.1 SDF state transition models for shadowing. 9 5.3.2 SDF stat
20、e transition models for chaining 21 6 Detailed operation procedure 25 6.1 ChainedExecute procedure . 25 6.1.1 General description 25 6.1.2 Parameters . 25 6.1.3 Invoking entity (SDF) 26 6.1.4 Responding entity (SDF). 26 6.2 IN-ChainedAddEntry procedure. 27 6.2.1 General description 27 6.2.2 Paramete
21、rs . 27 6.2.3 Invoking entity (SDF) 27 6.2.4 Responding entity (SDF). 28 6.3 IN-ChainedModifyEntry procedure 28 6.3.1 General description 28 6.3.2 Parameters . 28 6.3.3 Invoking entity (SDF) 28 6.3.4 Responding entity (SDF). 28 6.4 IN-ChainedRemoveEntry procedure 29 6.4.1 General description 29 iv I
22、TU-T Rec. Q.1248.5 (07/2001) Page 6.4.2 Parameters . 29 6.4.3 Invoking entity (SDF) 29 6.4.4 Responding entity (SDF). 29 6.5 IN-ChainedSearch procedure 29 6.5.1 General description 29 6.5.2 Parameters . 30 6.5.3 Invoking entity (SDF) 30 6.5.4 Responding entity (SDF). 30 6.6 IN-CoordinateShadowUpdate
23、 procedure 30 6.6.1 General description 30 6.6.2 Parameters . 30 6.6.3 Supplier entity (SDF). 31 6.6.4 Consumer entity (SDF) 32 6.7 IN-DSABind procedure 33 6.7.1 General description 33 6.7.2 Parameters . 33 6.7.3 Invoking Entity (SDF). 33 6.7.4 Responding entity (SDF). 34 6.8 IN-DSAShadowBind proced
24、ure . 34 6.8.1 General Description. 34 6.8.2 Parameters . 35 6.8.3 Supplier entity (SDF). 35 6.8.4 Consumer entity (SDF) 37 6.9 IN-RequestShadowUpdate procedure. 38 6.9.1 General description 38 6.9.2 Parameters . 38 6.9.3 Supplier entity (SDF). 39 6.9.4 Consumer entity (SDF) 39 6.10 IN-Unbind proced
25、ure 40 6.10.1 General description 40 6.10.2 Parameters . 40 6.10.3 Inviting entity (SDF in shadowing). 40 6.10.4 Responding entity (SDF in shadowing). 41 6.10.5 Invoking entity (SDF in directory access). 42 6.10.6 Responding entity (SDF in directory access) 42 6.10.7 Invoking entity (Initiating SDF
26、in traffic flow control) 43 6.10.8 Responding entity (Responding SDF in traffic flow control) . 43 6.11 IN-UpdateShadow procedure . 43 6.11.1 General description 43 ITU-T Rec. Q.1248.5 (07/2001) v Page 6.11.2 Parameters . 44 6.11.3 Supplier entity (SDF). 44 6.11.4 Consumer entity (SDF) 45 6.12 TFCBi
27、nd procedure 46 6.12.1 General description 46 6.12.2 Invoking entity (initiating SDF) 46 6.12.3 Responding entity (responding SDF) 47 6.13 TrafficFlowControl procedure 47 6.13.1 General description 47 6.13.2 Parameters . 48 6.13.3 Invoking entity (Initiating SDF) 48 6.13.4 Responding entity (Respond
28、ing SDF) 48 6.14 Operation timer values 49 7 Parameters. 49 7.1 AgreementID 49 7.2 Argument 49 7.3 ControlType 49 7.4 Duration 50 7.5 IN-ChainedArgument . 50 7.6 IN-ChainedResult . 52 7.7 Information . 52 7.8 LastUpdate 52 7.9 RequestedStrategy 52 7.10 Result 53 7.11 Security . 53 7.12 SecurityParam
29、eters . 53 7.13 TfcCriteria. 53 7.14 UpdatedInfo 53 7.15 UpdateStrategy 54 7.16 UpdateTime 54 7.17 UpdateWindow . 54 7.18 WasChained 54 8 Errors 54 8.1 Operation related error procedures . 54 8.1.1 AttributeError 55 8.1.2 ExecutionError. 56 8.1.3 IN-DirectoryBindError 56 vi ITU-T Rec. Q.1248.5 (07/2
30、001) Page 8.1.4 IN-DSAReferral. 57 8.1.5 NameError . 57 8.1.6 SecurityError . 58 8.1.7 ServiceError. 59 8.1.8 ShadowError 59 8.1.9 TFCBindError 60 8.1.10 UpdateError . 60 9 Service assumed from TCAP 61 9.1 Normal procedures 61 9.2 Abnormal procedures 61 9.3 Dialogue handling. 61 9.3.1 Dialogue estab
31、lishment 61 9.3.2 Dialogue continuation 61 9.3.3 Dialogue termination . 61 9.3.4 User Abort . 61 9.3.5 Provider Abort . 61 9.3.6 Mapping to TC Dialogue Primitives . 62 9.4 Component Handling 63 9.4.1 Procedures for INAP Operations. 63 9.4.2 Mapping to TC Component parameters 63 Annex A ASN.1 Definit
32、ions (electronic attachment) . 63 ITU-T Rec. Q.1248.5 (07/2001) 1 ITU-T Recommendation Q.1248.5 Interface Recommendation for Intelligent Network Capability Set 4: SDF-SDF interface11 Scope This Recommendation belongs to the Q.1248.x family of ITU-T Recommendations for IN Capability Set 4. It specifi
33、es the protocol on the SDF-SDF interface and provides a description of the aspects of the SDF and SDF Functional Entities which are involved in the realization of this interface. 2 References All ITU-T Recommendations and other references are identified in ITU-T Q.1248.1. 3 Abbreviations and acronym
34、s All abbreviations and acronyms used in this text are defined in ITU-T Q.1248.1. 4 Introduction 4.1 SDF-SDF relationship This 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 in
35、ter-network purposes. The SDF-SDF relationship supports messages for services when no call is actually taking place (call unrelated) as well as during call processing. For the most part, the call unrelated actions are to support the registration, authentication, encryption and handover procedures fo
36、r terminal and personal mobility. The SDF-SDF relationship is also one of a limited set of relationships to support inter-networking. 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 f
37、rom other public networks. The SDF-SDF relationship is used for various purposes. Each of the purposes can apply to the intra-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
38、 not stored within the SDF to complete a request for service data by another SDF. A crucial aspect of this relationship is security necessary to support network isolation and inter networking. b) Secured Copying of Service Data between SDFs. In this case a SDF copies a portion of service data which
39、is controlled by another SDF. A crucial aspect of this relationship is the keeping of the original security and access information relation to the service data once the data has been copied and ensuring that copies of data are deleted when no longer required. _ 1This Recommendation includes an elect
40、ronic attachment containing Annex A, ASN.1 definitions. 2 ITU-T Rec. Q.1248.5 (07/2001) 4.2 Introduction to the IN X.500 DSP and DISP subset The purpose of the SDF-SDF interface is to allow the transfer of copies of service profiles from one SDF to another and to manage the copies within the databas
41、e network. The X.500 functionalities cover more than the functionalities needed to fulfil the IN CS-4 requirements. This clause tries to indicate which aspects of the DSP and DISP should be considered and supported and which should be left out or ignored. Profiling is used as a means to present the
42、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 traffic and processing time. This is the reason why the parameters are removed unless they are absolutely necessary when they ar
43、e 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 to its actual description in the 1997 edition of the Directory. For convenience and clarity this profile is defined using A
44、SN.1 subtyping facilities, however, these definitions do not form a protocol specification. This simply indicates which parameters an implementation should not send. It does not change the behaviour of the receiving entity which shall still be capable of decoding values which conform to the original
45、 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 for IN CS-4. They are as follows: Assumption 1: The agreements between network operators concerning the transfer of da
46、ta are defined off-line (e.g. management operations). The establishOperationalBinding operation is only used to activate an agreement. Assumption 2: The agreements cannot be modified by an online operation. Assumption 3: The terminateOperationalBinding operation is used to end an agreement between t
47、wo 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 for future associations between the two networks; therefore, this information should be retained. Assumption 4: Th
48、e 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. The modification requests are passed to the master copy by using a chained operation. Copies are updated on ch
49、anges. 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. 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
