ATIS 0410104-0002-2007 Unified Ordering Model-Volume IV Generic Implementation Guidelines.pdf

1、 ATIS-0410104-0002 Unified Ordering Model (UOM) Volume IV GIG Generic Implementation Guideline Issue 2 ATIS 0410104-0002 UOM Volume IV Issued 03/23/2007 Generic Implementation Guidelines 2 The Alliance for Telecommunication Industry Solutions (ATIS) is a technical planning and standards development

2、organization that is committed to rapidly developing and promoting technical and operations standards for the communications and related information technologies industry worldwide using a pragmatic, flexible and open approach. Over 1,100 participants from more than 350 communications companies are

3、active in ATIS 23 industry committees and its Incubator Solutions Program. NOTE - The users attention is called to the possibility that compliance with this standard may require use of an invention covered by patent rights. By publication of this standard, no position is taken with respect to the va

4、lidity of this claim or any patent rights in connection therewith. The patent holder has, however, filed a statement of willingness to grant license under these rights on reasonable and nondiscriminatory terms and conditions to applicants desiring to obtain such a license. Details may be obtained fr

5、om the publisher. ATIS-0410104-0002 Unified Ordering Model (UOM) Volume IV Generic Implementation Guideline Is an ATIS standard developed by the UOM Committees under the ATIS Ordering and Billing Forum (OBF). Published by Alliance for Telecommunications Industry Solutions 1200 G Street, NW, Suite 50

6、0 Washington, DC 20005 Copyright 2007 by Alliance for Telecommunications Industry Solutions All rights reserved. No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher. For information contact A

7、TIS at 202.628.6380. ATIS is online at . Printed in the United States of America. ATIS 0410104-0002 UOM Volume IV Issued 03/23/2007 Generic Implementation Guidelines 3 Notice of Disclaimer and Limitation of Liability The information provided in this document is directed solely to professionals who h

8、ave the appropriate degree of experience to understand and interpret its contents in accordance with generally accepted engineering or other professional standards and applicable regulations. No recommendation as to products or vendors is made or should be implied. NO REPRESENTATION OR WARRANTY IS M

9、ADE THAT THE INFORMATION IS TECHNICALLY ACCURATE OR SUFFICIENT OR CONFORMS TO ANY STATUTE, GOVERNMENTAL RULE OR REGULATION, AND FURTHER, NO REPRESENTATION OR WARRANTY IS MADE OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR AGAINST INFRINGEMENT OF INTELLECTUAL PROPERTY RIGHTS. ATIS SHALL

10、NOT BE LIABLE, BEYOND THE AMOUNT OF ANY SUM RECEIVED IN PAYMENT BY ATIS FOR THIS DOCUMENT, WITH RESPECT TO ANY CLAIM, AND IN NO EVENT SHALL ATIS BE LIABLE FOR LOST PROFITS OR OTHER INCIDENTAL OR CONSEQUENTIAL DAMAGES. ATIS EXPRESSLY ADVISES ANY AND ALL USE OF OR RELIANCE UPON THIS INFORMATION PROVID

11、ED IN THIS DOCUMENT IS AT THE RISK OF THE USER. ATIS 0410104-0002 UOM Volume IV Issued 03/23/2007 Generic Implementation Guidelines 4 Abstract: This Generic Implementation Guideline (GIG) serves as a template for the development of Joint Implementation Agreements between the Customer and the Provide

12、r within the UMA application domain. As a template, this document contains generic specifications and recommendations for the electronic exchange of UOM application information between Customer and Providers. All items within this document are open to pair-wise negotiations. This document relates to

13、 specific Industry documents as it pertains to each UOM domain. Please review the table in Appendix J: References to identify associated documentation pertaining to your intended application domain. Although the GIG is a shared document with the UOM Committees, the OBF Wireless Committee publishes t

14、he Wireless Intercarrier Communications Interface Specification (WICIS) as a standard for all wireless companies and vendors. The transport protocol and interface records are implemented uniformly across the wireless industry. Any changes required to the standard are addressed via the ATIS Issue pro

15、cess, in order to maintain a single standard. This concept does not allow for individual negotiations and agreements; and therefore, this document has minimal use for wireless carriers. Change History Issue # Document Release Description of Changes Date 1 ATIS-0410104-0001 Initial Release January 20

16、06 2 ATIS-0410104-0002 Added comments specific to the wireless industry February 2007 ATIS 0410104-0002 UOM Volume IV Issued 03/23/2007 Generic Implementation Guidelines 5 1. BASIS AND SCOPE (JIA USE) 7 1.1 UOM REQUIREMENTS 7 1.2 PRINCIPAL PARTNERS. 8 1.3 CUSTOMER AND PROVIDER AGREEMENTS 8 1.3.1 Sta

17、tement of Agreement . 8 1.3.2 Definition of Agreement. 9 1.3.3 Implementation of Agreement 9 1.3.4 Logistics of Conducting Business 9 1.3.5 Channels of Communication 9 1.4 SCHEDULE UPDATES 9 1.5 CHANGE MANAGEMENT . 10 1.5.1 Change Management and Control. 11 1.5.2 Baseline 11 1.5.3 Procedure 11 1.5.4

18、 Process. 11 1.5.5 Reissue of Document 12 1.5.6 Change Control Contacts 13 1.5.7 Question Log 13 1.5.8 Publications and Documents . 14 2. CUSTOMER AND PROVIDER PROFILE REQUIREMENTS (JIA USE) 14 2.1 INTERCONNECTION PROFILE. 14 2.2 GATEWAY PROFILE 14 3. COMMUNICATION PROTOCOLS (JIA USE) 14 3.1 ACCESS

19、TOPOLOGY PROTOCOLS 15 4. TML USING SOAP (JIA USE). 15 4.1 TML HEADER COMPONENTS 15 4.2 INTERACTION OPERATIONAL MODES . 16 5. OPERATIONAL CONSIDERATIONS (JIA USE) 17 5.1 DATA SECURITY . 18 5.2 NON-REPUDIATION. 18 5.3 UOM/SOAP ERROR HANDLING. 18 5.3.1 UOM/SOAP Exceptions. 18 5.3.2 Business Level Stand

20、ard Errors. 18 5.3.3 Business Level Provider Specific Errors . 19 5.3.4 Restricted XML Special Characters. 19 6. PERFORMANCE (JIA USE) 19 6.1 RESPONSE TIME 19 6.2 RELIABILITY. 20 6.3 AVAILABILITY 20 6.4 THROUGHPUT . 20 7. FAULT MANAGEMENT (JIA USE). 20 7.1 FAULT MANAGEMENT CATEGORIES . 21 7.2 MEAN T

21、IME TO DETECTION 21 7.3 RECOVERY 21 7.3.1 Component Recovery . 22 7.4 REPORTING. 22 8. TIERED TECHNICAL SUPPORT SYSTEMS they are provided as a placeholder within the framework.) The Customer and Provider should review Section 3, Transport Architecture, within the tML Transport Profile (see Appendix

22、J: References) prior to documenting the communication protocol section within the JIA. For the wireless industry, communication protocols are standardized and addressed via WICIS Volume III. 3.1 Access Topology Protocols In support of the tML Transport Profile, the corresponding protocols and versio

23、ns should be agreed to and defined within this section. Protocol Examples of Version/Specification SOAP 1.1 TLS 1.0 (SSL 3.1) Privacy/Integrity Standard TDES in EDE/CBC mode for symmetric key encryption; RSA, DES-CBC, SHA1 cipher suite HTTP/ HTTP(s) 1.1 WSDL 1.1 Figure 7 Protocol Identification Temp

24、late 4. TML USING SOAP (JIA USE) 4.1 tML Header Components The tML Header is defined within the tML Transport Profile (Section 4, tML Messaging Using SOAP.) Customers and Providers should review the tML Transport Profile prior to documenting this section. The Customer and Provider should document th

25、e agreement reached within the JIA on the appropriate components of the tML Header based upon the corresponding Transaction Scenario and document it within the JIA. For the wireless industry, tML header components are standardized and addressed via WICIS Volumes II and III. Within UOM Volume II, the

26、 scenarios and models needed for message handling, delivery, notification and exceptions are defined based on the business processes as defined in UOM Volume I for the specific application involved (e.g., ASR, LSR, etc.). The Transaction Scenario table, from the tML Transport Profile, shows how tML

27、Header components can be used in different scenarios. Documentation should include how the “optional” and “conditional” tML Header components will be used between the Customer and Provider. ATIS 0410104-0002 UOM Volume IV Issued 03/23/2007 Generic Implementation Guidelines 16 4.2 Interaction Operati

28、onal Modes The Provider and Customer should review Section 5, Interaction Operational Modes, defined within the tML Transport Profile. This section will describe both the application interaction and the transport interaction between the Customer and Provider. The table below should be modified withi

29、n the JIA to identify the appropriate modes used between the Customer and Provider. The following table summarizes the mapping of UOM functions to tML Transport Interaction Mode Types: Phase: Examples of Message Type (Application Interaction) Transport Mode Type Pre-Order: Inquiry/Response Synchrono

30、us Request/Response Mode Order: Service Request Asynchronous Request/Response Mode Service Response Asynchronous Request/Response Mode Wireless Port Request Asynchronous Wireless Port Response Asynchronous Confirmation Notification One-way Notification Mode Error Clarification Notification One-way N

31、otification Mode Acknowledgement Response One-way Notification Mode Post Confirmation: Notification One-way Notification Mode Acknowledgement Response One-way Notification Mode Order Information Inquiry TBD based on response time. Will be either Asynchronous Request/Response Mode or Synchronous Requ

32、est/Response Mode Order Information Results TBD based on response time. Will be either Asynchronous Request/Response Mode or Synchronous Request/Response Mode Exception Response Note: Early implementations of UOM also allow for an Exception Response that is similar to the tML Transport Profiles Exce

33、ption Response as they were implemented in parallel. Exceptions which occur before a well formed tML is received will be put in SOAP FAULT and text will be sent along with the message. The SOAP FAULT message will contain a plain text listing of the exception and the SOAP FAULT details will contain t

34、he ATIS 0410104-0002 UOM Volume IV Issued 03/23/2007 Generic Implementation Guidelines 17 Phase: Examples of Message Type (Application Interaction) Transport Mode Type UOM Exception schema without the UOM Header. Applicable with any transport mode. Figure 8 Mapping of UOM Functions to tML Transport

35、Message Modes The interaction mode(s) selected is dependent on the process flows of the particular business application. 5. OPERATIONAL CONSIDERATIONS (JIA USE) This section provides a discussion on many of the operational issues that were identified within the transport of tML data between companie

36、s. It builds on the work efforts from the implementation planning to provide a complete picture of the transport specification in effect. The Customer and Provider should identify the details around the following items based on mode where appropriate. For the wireless industry, data security, extern

37、al timeouts, and error handling are standardized and addressed via WICIS Volume III. Operational Timer Definition Agreement Logging Data capture of transaction information should be done in sufficient quantity and at critical transfer points. This is done to facilitate internal investigations and re

38、solve customer issues. While there is no need to exchange log files with the customer there must be enough key data captured to uniquely identify a transaction. Timeouts Determine internal timeouts to be used and agree on external timeout settings. Retry The interval of retries and retry counts will

39、 need to determined and agreed upon. Result Waiting Define the time interval for this message. Data Security Determine authentication methods such as ATIS 0410104-0002 UOM Volume IV Issued 03/23/2007 Generic Implementation Guidelines 18 Operational Timer Definition Agreement digital certificates and

40、/or ID/Password. Non-repudiation Identify specific components as they relate to data security. Define XML attributes and method for exchange of public key. Figure 9 Operational Considerations Template 5.1 Data Security Authentication and authorization is required for accurate implementation of the i

41、nterface. Within the area of Data Security the Customer and Provider should consider but are not limited to the following: Digital Certificates ID/Password Digital Signatures (Public and Private Keys) - Required by tML Transport Combination of Digital Certificates, Digital Signatures, and ID/Passwor

42、d Customer Specific Identifiers - such as Customer Carrier Name Abbreviation (CCNA) or Company Code (CC) 5.2 Non-Repudiation Non-repudiation is an optional feature within the tML Transport Profile. There is significant computational overhead involved. Specific details should be documented below pert

43、aining to the implementation of the interface between the Customer and Provider. The tML Transport Profile defines the XML, which may be used for defining digital signatures. Additionally, the appropriate algorithms for defining a digital signature and the specific elements, which should be interrog

44、ated within the XML, should be agreed upon. 5.3 UOM/SOAP Error Handling Exceptions can occur during tML document exchange or processing. The Provider should identify the appropriate point within the request flow where an error may occur. 5.3.1 UOM/SOAP Exceptions The Customer and Provider should agr

45、ee on appropriate UOM/SOAP exceptions and document them in this section. The list of potential exceptions are listed in the tML Transport Profile. 5.3.2 Business Level Standard Errors Business level standard errors will result in a normal message response containing the error information in a UOM fo

46、rmat. The UOM schemas provide an Exception Response structure which could be used to pass this information. ATIS 0410104-0002 UOM Volume IV Issued 03/23/2007 Generic Implementation Guidelines 19 5.3.3 Business Level Provider Specific Errors Business level provider specific errors are handled and pro

47、cessed as business level standard errors. The only difference is that these are additional provider specific requirements which should be documented between the Customer and Provider. 5.3.4 Restricted XML Special Characters There are special characters that have a special meaning in XML and must be

48、handled per World Wide Web Consortium (W3C) recommendations (www.w3c.org). These characters include: Less than Ampersand stating that only one of several UOM Providers is unavailable. B. Customer/Provider X component failed, expects to be up by DDHHMM. C. Customer/Provider X operating in degraded mode. D. Customer/Provider X Schedule down time begins DDHHMM, ends DDHHMM. E. Order/Inquiry/No