TIA-41 691-E-2013 Mobile Application Part (MAP) Procedure - Annexes.pdf

1、 TIA-41.691-E February 2013Mobile Application Part (MAP) Procedure - Annexes ANSI/TIA-41.691-E-2013 APPROVED: FEBRUARY 6, 2013 NOTICE TIA Engineering Standards and Publications are designed to serve the public interest through eliminating misunderstandings between manufacturers and purchasers, facil

2、itating 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 such Standards and Publications shall not in any respect preclude any member or non-member of TIA from manu

3、facturing 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, either domestically or internationally. Standards and Publications are adopted by TIA in accordance with th

4、e 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 adopting the Standard or Publication. This Standard does not purport to address all safety problems associated wi

5、th 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 applicability of regulatory limitations before its use. (From Project No. SP-3-3590.691-RV5-A, formulated under the co

6、gnizance of the TIA TR-45 Mobile and Personal Communications Systems Standards, TR-45.8 Subcommittee on Core Networks- Mobile and Personal Communications Standards). Published by TELECOMMUNICATIONS INDUSTRY ASSOCIATION Standards and Technology Department 1320 N. Courthouse Road Arlington, VA 22201 U

7、.S.A. PRICE: Please refer to current Catalog of TIA TELECOMMUNICATIONS INDUSTRY ASSOCIATION STANDARDS AND ENGINEERING PUBLICATIONS or call IHS, USA and Canada (1-877-413-5187) International (303-397-2896) or search online at http:/www.tiaonline.org/standards/catalog/ All rights reserved Printed in U

8、.S.A. NOTICE OF COPYRIGHT This document is copyrighted by the TIA. Reproduction of these documents either in hard copy or soft copy (including posting on the web) is prohibited without copyright permission. For copyright permission to reproduce portions of this document, please contact the TIA Stand

9、ards Department or go to the TIA website (www.tiaonline.org) for details on how to request permission. Details are located at: http:/www.tiaonline.org/standards/catalog/info.cfm#copyright or Telecommunications Industry Association Technology (b) there is no assurance that the Document will be approv

10、ed by any Committee of TIA or any other body in its present or any other form; (c) the Document may be amended, modified or changed in the standards development or any editing process. The use or practice of contents of this Document may involve the use of intellectual property rights (“IPR”), inclu

11、ding pending or issued patents, or copyrights, owned by one or more parties. TIA makes no search or investigation for IPR. When IPR consisting of patents and published pending patent applications are claimed and called to TIAs attention, a statement from the holder thereof is requested, all in accor

12、dance with the Manual. TIA takes no position with reference to, and disclaims any obligation to investigate or inquire into, the scope or validity of any claims of IPR. TIA will neither be a party to discussions of any licensing terms or conditions, which are instead left to the parties involved, no

13、r will TIA opine or judge whether proposed licensing terms or conditions are reasonable or non-discriminatory. TIA does not warrant or represent that procedures or practices suggested or provided in the Manual have been complied with as respects the Document or its contents. If the Document contains

14、 one or more Normative References to a document published by another organization (“other SSO”) engaged in the formulation, development or publication of standards (whether designated as a standard, specification, recommendation or otherwise), whether such reference consists of mandatory, alternate

15、or optional elements (as defined in the TIA Engineering Manual, 4thedition) then (i) TIA disclaims any duty or obligation to search or investigate the records of any other SSO for IPR or letters of assurance relating to any such Normative Reference; (ii) TIAs policy of encouragement of voluntary dis

16、closure (see Engineering Manual Section 6.5.1) of Essential Patent(s) and published pending patent applications shall apply; and (iii) Information as to claims of IPR in the records or publications of the other SSO shall not constitute identification to TIA of a claim of Essential Patent(s) or publi

17、shed pending patent applications. TIA does not enforce or monitor compliance with the contents of the Document. TIA does not certify, inspect, test or otherwise investigate products, designs or services or any claims of compliance with the contents of the Document. ALL WARRANTIES, EXPRESS OR IMPLIED

18、, ARE DISCLAIMED, INCLUDING WITHOUT LIMITATION, ANY AND ALL WARRANTIES CONCERNING THE ACCURACY OF THE CONTENTS, ITS FITNESS OR APPROPRIATENESS FOR A PARTICULAR PURPOSE OR USE, ITS MERCHANTABILITY AND ITS NONINFRINGEMENT OF ANY THIRD PARTYS INTELLECTUAL PROPERTY RIGHTS. TIA EXPRESSLY DISCLAIMS ANY AN

19、D ALL RESPONSIBILITIES FOR THE ACCURACY OF THE CONTENTS AND MAKES NO REPRESENTATIONS OR WARRANTIES REGARDING THE CONTENTS COMPLIANCE WITH ANY APPLICABLE STATUTE, RULE OR REGULATION, OR THE SAFETY OR HEALTH EFFECTS OF THE CONTENTS OR ANY PRODUCT OR SERVICE REFERRED TO IN THE DOCUMENT OR PRODUCED OR R

20、ENDERED TO COMPLY WITH THE CONTENTS. 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

21、OF BUSINESS, 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

22、 THE CONTENTS HEREOF, AND THESE CONTENTS WOULD NOT BE PUBLISHED BY TIA WITHOUT SUCH LIMITATIONS. X.S0004-691-E v1.0123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960691-1 ANNEX A: Procedures for RANDC VerificationPART 6911 ANNEX A: PROCEDU

23、RES FOR RANDC VERIFICATIONThis annex is informative and is not considered part of this Standard.This annex describes an algorithm for verifying the value of RANDC received from an MS. Thealgorithm used to verify RANDC is internal to an MSC and, as such, it does not constitute anintersystem operation

24、.When an MSC receives RANDC(ms), the RANDC value reported by an MS, it shall perform thefollowing:1 IF the value of RANDC(ms) equals current RANDC1:1-1 Return to calling task, indicating that RANDC(ms) is valid and that the Random Number is current RAND.2 ELSEIF the value of RANDC(ms) equals pending

25、 RANDC:2-1 Return to calling task, indicating that RANDC(ms) is valid and that the Random Number is pending RAND.3 ELSEIF the value of RANDC(ms) equals ZERO:3-1 Return to calling task, indicating that RANDC(ms) is valid and that the Random Number is ZERO.4ELSE:4-1 Return to calling task, indicating

26、that RANDC(ms) is invalid.5 ENDIF.1RAND(n) is the random number currently transmitted by the MSC in the OMT of the serving cell. RAND(n-1) is the random number transmitted in the OMT of the serving cell immediately prior to RAND(n). RANDC is the eight most significant bits of RAND.X.S0004-691-E v1.0

27、ANNEX B: Procedures for SSD Management at AC123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960691-22 ANNEX B: PROCEDURES FOR SSD MANAGEMENT AT AC This annex is informative and is not considered part of this Standard.This annex describes an

28、 algorithm for managing updates to the SharedSecretData (SSD) at the AC.The algorithm used to manage updates is internal to an AC and, as such, it does not constitute anintersystem operation.When an AC initiates updating of an MSs SSD, it performs the following:1 A new value of SSD is calculated and

29、 is stored in the ACs database as the pending Shared Secret Data, pending SSD; the current value of the Shared Secret Data, current SSD, is also retained.2 IF AUTHR(ms), an Authentication Result from the MS, is received through an AuthenticationRequest INVOKE:2-1 Compute current AUTHR using the valu

30、e of current SSD.2-2 IF current SSD is not equal to pending SSD:2-2-1 Compute pending AUTHR using the value of pending SSD.2-3 ENDIF.2-4 IF AUTHR(ms) equals current AUTHR:2-4-1 Return to calling task, indicating that authentication was successful.2-5 ELSEIF current SSD is not equal to pending SSD an

31、d AUTHR(ms) equals pending AUTHR:2-5-1 Discard current SSD.2-5-2 Store the value of pending SSD as the current value.2-5-3 Return to calling task, indicating that authentication was successful.2-6 ELSE:2-6-1 Return to calling task, indicating that authentication was not successful.2-7 ENDIF.3 ENDIF.

32、4 IF a BaseStationChallenge INVOKE is received:4-1 Compute an Authentication Result (AUTHBS) using pending SSD and the Random Number (RANDBS) received in the BaseStationChallenge INVOKE.4-2 Return to calling task.5 ENDIF.6 IF an AuthenticationStatusReport INVOKE is received indicating that SSD updat

33、ing was successful:6-1 Discard current SSD.6-2 Store the value of pending SSD as the current value.6-3 Return to calling task.7 ENDIF.8 IF an AuthenticationStatusReport INVOKE is received indicating that SSD updating was not successful:X.S0004-691-E v1.01234567891011121314151617181920212223242526272

34、82930313233343536373839404142434445464748495051525354555657585960691-3 ANNEX B: Procedures for SSD Management atAC8-1 Discard pending SSD.8-2 Store current SSD in pending SSD.9 ENDIF.10 Return to calling task.X.S0004-691-E v1.0ANNEX C: Authentication Response Verification1234567891011121314151617181

35、92021222324252627282930313233343536373839404142434445464748495051525354555657585960691-43 ANNEX C: AUTHENTICATION RESPONSE VERIFICATIONThis annex is informative and is not considered part of this Standard.This annex describes algorithms for verifying authentication responses at the AC and the VLR(wh

36、en SSD is shared). These algorithms are used to verify responses and are internal to the AC andVLR, and as such, do not constitute intersystem operations.When an AC/HLR detects that its calculated value of AUTHR using the current SSD or pendingSSD (see Annex B) is not equal to the value received fro

37、m the MS, then:1 Optionally perform Unique Challenge.2 IF the Unique Challenge is not performed OR IF (AuthenticationResponseUnique :2-1 Deny or allow service according to the authentication procedures of the service provider.3 ENDIF.When the VLR (if SSD is shared with the current serving system) de

38、tects that its calculated value ofAUTHR is not equal to the value received from the MS, then:4 IF the MS is marked pending SSD update:4-1 Forward AuthenticationRequest INVOKE to the AC/HLR.5ELSE:5-1 Send the appropriate Security Status Report to the AC/HLR.5-2 Provide call treatment as specified in

39、the RETURN RESULT.6 ENDIF.(Note: if access is denied, the HLR can optionally take additional protective steps; such as,instructing the VLR to change the authorization period of the mobile)When an AC/HLR detects that its calculated value of AuthenticationResponseUnique (AUTHU)using current SSD or pen

40、ding SSD (see Annex B) is not equal to the value received from the MS,then deny or allow service according to the authentication procedures of the service provider at theAC/HLR.When the MSC detects that its value of AUTHU is not equal to the value received from the MS, then:1 Send the appropriate Au

41、thenticationStatusReport INVOKE to the AC/HLR.2 Provide call treatment as specified in the RETURN RESULT. If the Unique Challenge was performed due to an SSD update, the AC/HLR may decide to perform an SSD update when the next transaction occurs.(Note: if access is denied, the HLR can optionally tak

42、e additional protective steps; such as,instructing the VLR to change the authorization period of the mobile)AUTHU AUTHUAUTHR AUTHRAUTHU AUTHUX.S0004-691-E v1.0123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960691-5 ANNEX C: Authentication

43、Response VerificationWhen an SSD update failure occurs, the MS shall notify the MSC. (e.g., the MS indicates an SSDupdate failure in the SSD update Confirmation/ACK, according to TDMA.) The MSC shall send theAC/HLR a failure indicator in the AuthenticationStatusReport INVOKE. Authentication procedur

44、esat the AC/HLR may result in one of the following actions:1 Attempt to update the SSD at the MS.2 Maintain the old SSD at the AC/HLR and allow service for the MS at the Visited Serving System.3 Maintain the old SSD at the AC/HLR and deny service for the MS at the Visited Serving System.AUTHUBS AUTH

45、BSX.S0004-691-E v1.0ANNEX D: SMS Air Interface Delivery Point-to-Point123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960691-64 ANNEX D: SMS AIR INTERFACE DELIVERY POINT-TO-POINTThis annex is informative and is not considered part of this S

46、tandard.The following tables describe the parameters used in the illustrative SMD-REQUEST, SMD-ACK,and SMD-NAK messages. These messages must be converted into the appropriate actual airinterface messages. It is further assumed that a given message transaction can be correlated acrossthe air interfac

47、e, so the address parameters may not be present in the responses depending on theunderlying air interface technology.Notes:a. Include to identify the MS on the air interface.b. Include on air interfaces that support more than one teleservice.c. Include to identify an intermediate destination (e.g.,

48、originating MC) if theSMD-REQUEST is mobile originated, if supported by the specific air interface protocoland if not carried by the underlying data transport.d. Include to identify the destination SME. Required for mobile originated SMD-REQUEST.Include for mobile terminated SMD-REQUEST if supported

49、 by the underlying air interfaceand if different from the air interface destination address (e.g., MSID).e. Include if applicable.f. Include to identify the originating SME. Required for mobile terminated SMD-REQUEST.Include for mobile originated SMD-REQUEST if supported by the underlying air interfaceand if different from the underlying air interface originating address (e.g., MSID). Table 1 SMD-REQUEST ParametersSMD-REQUEST Parameters Timer: SADT or SAOTFieldType NotesElectronicSerialNumber O aMSID O aBearerData MTeleserviceIdentifier O bDestinationAddress O cOriginalDestination