TIA-41 590-E-2004 Part 590 Wireless Radiotelecommunications Intersystem Operations C MAP Compatibility Signaling Protocols《Part 590 无绳无线电通信内部系统操作 MAP兼容性信令协议》.pdf

《TIA-41 590-E-2004 Part 590 Wireless Radiotelecommunications Intersystem Operations C MAP Compatibility Signaling Protocols《Part 590 无绳无线电通信内部系统操作 MAP兼容性信令协议》.pdf》由会员分享，可在线阅读，更多相关《TIA-41 590-E-2004 Part 590 Wireless Radiotelecommunications Intersystem Operations C MAP Compatibility Signaling Protocols《Part 590 无绳无线电通信内部系统操作 MAP兼容性信令协议》.pdf（14页珍藏版）》请在麦多课文档分享上搜索。

1、 TIA-41.590-E (Revision of TIA-41.D) October 2010 Part 590: Wireless Radiotelecommunications Intersystem Operations MAP Compatibility Signaling Protocols ANSI/TIA-41.590-E-2004 APPROVED: APRIL 20, 2004 REAFFIRMATION: SEPTEMBER 1, 2010 NOTICE TIA Engineering Standards and Publications are designed to

2、 serve the public interest through eliminating misunderstandings between manufacturers and purchasers, facilitating interchangeability and improvement of products, and assisting the purchaser in selecting and obtaining with minimum delay the proper product for their particular need. The existence of

3、 such Standards and Publications shall not in any respect preclude any member or non-member of TIA from manufacturing or selling products not conforming to such Standards and Publications. Neither shall the existence of such Standards and Publications preclude their voluntary use by Non-TIA members,

4、 either domestically or internationally. Standards and Publications are adopted by TIA in accordance with the American National Standards Institute (ANSI) patent policy. By such action, TIA does not assume any liability to any patent owner, nor does it assume any obligation whatever to parties adopt

5、ing the Standard or Publication. This Standard does not purport to address all safety problems associated with its use or all applicable regulatory requirements. It is the responsibility of the user of this Standard to establish appropriate safety and health practices and to determine the applicabil

6、ity of regulatory limitations before its use. (From Standards Proposal No. 3-3590.590-RV5, formulated under the cognizance of the TIA TR-45.2 Subcommittee on Wireless Intersystem Technology.) Published by TELECOMMUNICATIONS INDUSTRY ASSOCIATION 2002 Standards and Technology Department 2500 Wilson Bo

7、ulevard Arlington, VA 22201 U.S.A. PRICE: Please refer to current Catalog of TIA TELECOMMUNICATIONS INDUSTRY ASSOCIATION STANDARDS AND ENGINEERING PUBLICATIONS or call Global Engineering Documents, USA and Canada (1-800-854-7179) International (303-397-7956) or search online at http:/www.tiaonline.o

8、rg/standards/search_n_order.cfm All rights reserved Printed in U.S.A. PLEASE! DONT VIOLATE THE LAW! This document is copyrighted by the TIA and may not be reproduced without permission. Organizations may obtain permission to reproduce a limited number of copies through entering into a license agreem

9、ent. For information, contact: Global Engineering Documents 15 Inverness Way East Englewood, CO 80112-5704 U.S.A. or call U.S.A. and Canada 1-800-854-7179, International (303) 397-7956 NOTICE OF DISCLAIMER AND LIMITATION OF LIABILITY The document to which this Notice is affixed has been prepared by

10、one or more Engineering Committees of the Telecommunications Industry Association (“TIA”). TIA is not the author of the document contents, but publishes and claims copyright to the document pursuant to licenses and permission granted by the authors of the contents. TIA Engineering Committees are exp

11、ected to conduct their affairs in accordance with the TIA Engineering Manual (“Manual”), the current and predecessor versions of which are available at http:/www.tiaonline.org/standards/sfg/engineering_manual.cfm. TIAs function is to administer the process, but not the content, of document preparati

12、on in accordance with the Manual and, when appropriate, the policies and procedures of the American National Standards Institute (“ANSI”). THE USE OR PRACTICE OF CONTENTS OF THIS DOCUMENT MAY INVOLVE THE USE OF INTELLECTUAL PROPERTY RIGHTS (“IPR”), INCLUDING PENDING OR ISSUED PATENTS, OR COPYRIGHTS,

13、 OWNED BY ONE OR MORE PARTIES. TIA MAKES NO SEARCH OR INVESTIGATION FOR IPR. WHEN IPR CONSISTING OF PATENTS AND PUBLISHED PATENT APPLICATIONS ARE CLAIMED AND CALLED TO TIAS ATTENTION, A STATEMENT FROM THE HOLDER THEREOF IS REQUESTED, ALL IN ACCORDANCE WITH THE MANUAL. TIA TAKES NO POSITION WITH REFE

14、RENCE TO, AND DISCLAIMS ANY OBLIGATION TO INVESTIGATE OR INQUIRE INTO, THE SCOPE OR VALIDITY OF ANY CLAIMS OF IPR. ALL WARRANTIES, EXPRESS OR IMPLIED, ARE DISCLAIMED, INCLUDING WITHOUT LIMITATION, ANY AND ALL WARRANTIES CONCERNING THE ACCURACY OF THE CONTENTS, ITS FITNESS OR APPROPRIATENESS FOR A PA

15、RTICULAR PURPOSE OR USE, ITS MERCHANTABILITY AND ITS NON-INFRINGEMENT OF ANY THIRD PARTYS INTELLECTUAL PROPERTY RIGHTS. TIA EXPRESSLY DISCLAIMS ANY AND ALL RESPONSIBILITIES FOR THE ACCURACY OF THE CONTENTS AND MAKES NO REPRESENTATIONS OR WARRANTIES REGARDING THE CONTENTS COMPLIANCE WITH ANY APPLICAB

16、LE STATUTE, RULE OR REGULATION. TIA SHALL NOT BE LIABLE FOR ANY AND ALL DAMAGES, DIRECT OR INDIRECT, ARISING FROM OR RELATING TO ANY USE OF THE CONTENTS CONTAINED HEREIN, INCLUDING WITHOUT LIMITATION ANY AND ALL INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES (INCLUDING DAMAGES FOR LOSS OF BU

17、SINESS, LOSS OF PROFITS, LITIGATION, OR THE LIKE), WHETHER BASED UPON BREACH OF CONTRACT, BREACH OF WARRANTY, TORT (INCLUDING NEGLIGENCE), PRODUCT LIABILITY OR OTHERWISE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THE FOREGOING NEGATION OF DAMAGES IS A FUNDAMENTAL ELEMENT OF THE USE OF THE

18、CONTENTS HEREOF, AND THESE CONTENTS WOULD NOT BE PUBLISHED BY TIA WITHOUT SUCH LIMITATIONS. TIA-41-590-E123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960590-1 MAP COMPATIBILITY GUIDELINES AND RULESPART 5901 MAP COMPATIBILITY GUIDELINES AN

19、D RULESWhile the following sections outline guidelines and rules which will in the near term be beneficialto implementation of this standard, other activities which may impact these rules are in progress. Assuch, the remainder of this Section, “MAP Compatibility Guidelines and Rules” may be subject

20、tochange and revision based on future TIA-41 recommendations.This is to ensure that there is no long term impediment to Cellular Radiotelecommunicationsnetworks to evolve and implement significant new functionality. Also, to better allow for the longerterm alignment of TIA-41 with emerging internati

21、onal standards.1.1 ACHIEVING FORWARD COMPATIBILITY AND BACKWARD COMPATIBILITYFollowing are some general considerations for enhancing and developing protocols.1.1.1 Forward CompatibilityWhen developing a new protocol or enhancing an existing protocol, it is important to remember thata network entity

22、using one version of protocol may, in the future, need to communicate with networkentities using the enhanced version of the basic protocol. Hence, the protocol should be easy toenhance (e.g., easy to add new optional parameters). In addition, procedures should be built into theexisting protocol to

23、handle the situations when new messages, known messages with unknownparameters, or known parameters with unknown codes are received.1.1.2 Backward CompatibilityWhen enhancing an existing protocol, it is important to keep in mind that a network entity using oneversion of protocol may need to communic

24、ate with network entities using older versions of sameprotocol. Hence, the protocol should not be changed abruptly into a form which the earlier protocolversions cannot even interpret. For example, one should not change a fixed length mandatoryparameter to an optional parameter in an existing messag

25、e.1.2 GUIDELINES FOR FORWARD COMPATIBILITYTIA-41 MAP shall contain a mechanism for forward compatibility. The following list and tablecontain the basic requirements of the mechanism:1. These guidelines take precedence over the Abnormal Procedures section of TCAP (ANSIT1.114-1988, section 5).TIA-41-5

26、90-EGUIDELINES FOR FORWARD COMPATIBILITY123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960590-22. Include the ability to send a TCAP REJECT component indicating that the receivedinformation was not understood when indicated by the followin

27、g table.3. Send this TCAP REJECT component to the network entity that transmitted the confusinginformation if the necessary routing information is available.4. For existing protocols, state the action to be taken on receipt of spare or reserved values ofdefined parameters (e.g., treat as appropriate

28、 default values). If no default is explicitlyspecified, the action listed in the following table should occur.5. Only send messages that require an acknowledgment a limited number of times (e.g., 3). Ifno response is received, the sending network entity should assume that the facility is notavailabl

29、e and inform local management.6. All messages may have new optional parameters added in any revision.Table 1 Forward Compatibility Guidelines for Handling Incoming Messages and ParametersProblem Response1 Unrecognized Operation Code Identifier. REJECT (Problem Specifier = Unrecognized Operation Code

30、)2 Unrecognized Package Type Identifier. REJECT (Problem Specifier = Unrecognized Package Type)3 Unrecognized Parameter Identifier at intermediate network entity.Transit parameter unchanged4 Unrecognized Parameter Identifier at end network entity.Ignore parameter5 Parameter with fixed length not the

31、 correct length.REJECT (Problem Specifier = IncorrectParameter)6 Variable length parameter has Parameter Length shorter than the minimum expected.RETURN ERROR (Error Code = ParameterError)7 Variable length parameter has Parameter Length longer than the maximum expected.Ignore additional octets8 Mand

32、atory parameter missing. REJECT (Problem Specifier = IncorrectParameter)9 Optional parameter required by context of message is missing.RETURN ERROR (Error Code = MissingParameter)10 Optional parameter forbidden by presence or value of another parameter with stated precedence between them.Ignore para

33、meter11 Optional parameter forbidden by presence of another parameter with no stated precedence.RETURN ERROR (Error Code = ParameterError)12 Parameter with known Parameter Identifier is not expected in this message.Ignore parameterTIA-41-590-E123456789101112131415161718192021222324252627282930313233

34、343536373839404142434445464748495051525354555657585960590-3 GUIDELINES FOR FORWARD COMPATIBILITY13 Parameter value No effect, Not appli-cable, Not specified, Not used, Reserved, or Unknown. Use default value, if specified, otherwise ignore the parameter14 Parameter value otherwise unrecognized or in

35、valid.RETURN ERROR (Error Code = UnrecognizedParameterValue)15 Recognized parameter with valid values included more times than expected.Ignore additional occurrences of parameter. This may indicate that a parameter that occurs once in the current revision of TIA-41 is allowed to occur multiple times

36、 in a later revision. For compatibility, any single occurrence has to be acceptable.Table 1 Forward Compatibility Guidelines for Handling Incoming Messages and Parameters (Continued)Problem ResponseTIA-41-590-EGUIDELINES FOR BACKWARD COMPATIBILITY12345678910111213141516171819202122232425262728293031

37、3233343536373839404142434445464748495051525354555657585960590-41.3 GUIDELINES FOR BACKWARD COMPATIBILITYAll future revisions of TIA-41 MAP from IS-41 Revision B onward, shall contain a mechanism forbackward compatibility. The following list contains the basic guidelines to be included.1.3.1 Existing

38、 Messagesa. The ability of receiving any existing messages shall be possible, since the removal of amessage implies the removal of a function.b. The effect of receiving any existing message, parameter, or function in a new version, mustbe the same as that in previous versions. The effects of new par

39、ameters or parameter valuesshall thus be purely additive.c. For TIA-41 the nature of a transaction shall not change to or from Unidirectional.1.3.2 Parameters in Existing MessagesMessage parameters in the Parameter Set consist of two basic types, mandatory and optional, andneed not occur in pre-defi

40、ned order. All mandatory and optional parameters have variable length,although some parameters may have specified their length.The following guidelines shall apply:a. Optional parameters shall not become mandatory.b. Mandatory parameters shall not become optional.c. Additional mandatory parameters s

41、hall not be added to an existing message.d. Additional optional parameters may be added to an existing message.e. Existing mandatory parameters shall not be removed from existing messages.f. The range of any parameter for an existing message shall not be reduced.g. The meaning of any defined paramet

42、er value shall not be changed on an existing message.h. There are no restrictions on the parameters for new messages.i. The minimum length of the data portion of a variable length parameter is one octet, unlessotherwise specified.j. CHOICEs may be extended (e.g., a CHOICE OF (ParameterA, ParameterB)

43、 may beextended to a CHOICE OF (ParameterA, ParameterB, ParameterC).TIA-41-590-E123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960590-5 GUIDELINES FOR BACKWARD COMPATIBILITY1.3.3 New Messagesa. New messages may be added after a recommendat

44、ion has been published; however,network entities that do not recognize these new messages shall reject them, indicating thatthe information was not recognized.b. The “information not recognized” message shall never be sent in response to a received“information not recognized” message (e.g., a REJECT

45、 message should never be sent inresponse to a received REJECT message), nor in response to other recognized messagesreceived in the wrong call state. Appropriate default action shall be defined to handle thesesituations.1.3.4 New ParametersNew optional parameters may be added to existing messages af

46、ter a recommendation has beenpublished; however, network entities that do not recognize these new parameters could ignore them.Addition of new parameters may be subjected to Basic Encoding Rules (BER) restrictions, asdefined in Parameter Type definitions.1.3.5 New Parameter FieldsNew fields may be a

47、dded to, or spare fields may be used in existing parameters; however, networkentities that do not recognize these new fields may either respond with a message indicating that theinformation was not recognized or use the default values specified for these parameters.1.3.6 New Parameter ValuesPrevious

48、ly spare, reserved, or unallocated parameter values may be used. These shall be treated atthe receiving network entity as defined in item 4 of Section 1.2.TIA-41-590-EGUIDELINES FOR BACKWARD COMPATIBILITY123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960590-6