ANSI TIA-41.350-E-2012 Mobile Application Part (MAP) - Voice Feature Scenarios MDN-Based Validation《移动应用部分(MAP).声音特征场景 基于MDN的确认》.pdf

1、 TIA-41.350-E August 2012Mobile Application Part (MAP) - Voice Feature Scenarios: MDN-Based Validation ANSI/TIA-41.350-E-2012 APPROVED: AUGUST 9, 2012 NOTICE TIA Engineering Standards and Publications are designed to serve the public interest through eliminating misunderstandings between manufacture

2、rs 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 such Standards and Publications shall not in any respect preclude any member or non

3、-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, either domestically or internationally. Standards and Publications are adopted by T

4、IA 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 adopting the Standard or Publication. This Standard does not purport to address all safet

5、y 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 applicability of regulatory limitations before its use. (From Project No. SP-3-3590.350-RV5-A,

6、 formulated under the cognizance 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 2500 Wilson Boulevard

7、 Arlington, VA 22201 U.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

8、 reserved Printed in U.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

9、 contact the TIA Standards 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 D

10、ocument will be approved 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

11、 rights (“IPR”), including 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 r

12、equested, all in accordance 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 th

13、e parties involved, nor 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

14、 the Document contains 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

15、 mandatory, alternate 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 encourag

16、ement of voluntary disclosure (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 Essent

17、ial Patent(s) or published 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 WARRANTI

18、ES, EXPRESS OR IMPLIED, 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 EXPR

19、ESSLY DISCLAIMS ANY AND 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 DOC

20、UMENT OR PRODUCED OR RENDERED 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 (INCLU

21、DING DAMAGES FOR LOSS 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

22、 ELEMENT OF THE USE OF THE CONTENTS HEREOF, AND THESE CONTENTS WOULD NOT BE PUBLISHED BY TIA WITHOUT SUCH LIMITATIONS. REVISION HISTORYRevision Date RemarksX.S0004-350-E v1.0 January 2009 Initial publication.X.S0004-350-E v1.012345678910111213141516171819202122232425262728293031323334353637383940414

23、2434445464748495051525354555657585960350-1 INTRODUCTION1 INTRODUCTIONUnless otherwise noted, the scenarios in this section depict features operating individually; i.e.,feature interactions are not considered unless specifically noted. The scenarios in this part do not include a complete listing of o

24、peration parameters, either in thefigures or in the accompanying text descriptions. Parameters are included where they aredeemed necessary to improve the understanding of the scenario. For a complete description ofthe parameters associated with each operation, refer to Parts 540 and 550. 2 MDN-Based

25、 ValidationThis section depicts the interactions between network entities in various situations related toMDN-Based subscription validation. These scenarios are for illustrative purposes only.2.1 Successful MDN-Based ValidationThis scenario illustrates successful MDN-Based subscription validation wh

26、en the Serving MSCdetermines the originating subscriber is eligible for special service treatment. In this case, theoriginating subscribers profile information is not available requiring the Serving MSC to senda QualificationRequest2 INVOKE to the Originating MSs HLR and retrieve the originatingsubs

27、cribers profile information before delivering the call to the Terminating party. Figure 1 Successful MDN-Based ValidationQUALREQ2 MDN, MSCID, MYTYP, QUALCODE, ServiceQRTqualreq2 AUTHPER, HLRID, MYTYP, Profile,abedMSC/VLR HLRPlatformIAM (CdPN=dedicated number)IAM CdPN=CallBack No., CgPN=MDN)IAM (CdPN

28、=CallBack No., CgPN=MDN)IAM (CdPN=dedicated number)cfPSTNSYSACCTYPE, TRANSCAP(MIN, IMSI or both), ESNX.S0004-350-E v1.0MDN-Based Validation123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960350-2a. A mobile subscriber originates a call to a

29、 dedicated number, e.g., voice mail, from alandline phone. An ISUP IAM message is sent to the Serving MSC.b. The Serving MSC receives the incoming call and determines that the dialed numbertranslates to a dedicated route to a service platform, e.g., voice mail system and an IAM issent to this system

30、.c. The service platform is only aware of the MDN (mobile directory number) of thesubscriber, e.g., the subscriber is required to enter their MDN in order to access theirmessages. The service platform initiates a new call , e.g., to a callback number, on behalfof the subscriber and a new IAM is sent

31、 to the Serving MSC with the calling party numberset to the MDN.d. The Serving MSC determines that originating validation is required for the incoming calland searches the VLR for a record corresponding to the originating subscribers MDN. Inthis case, a corresponding record is not found. This result

32、s in MAP QualificationRequest2(QUALREQ2) INVOKE message being sent to the Originating MSs Home HLR to retrievethe subscribers profile information including the MIN, IMSI or both.e. The HLR locates the subscribers record using the supplied MDN, performs its validationfunctions, and returns a qualreq2

33、 with the subscribers profile information and MIN,IMSI or both and ESN to the requesting Serving VLR.f. The Serving MSC finishes originating validation and delivers the call to the PSTN.X.S0004-350-E v1.0123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525

34、354555657585960350-3 MDN-Based Validation2.2 Successful MDN-Based Validation with WIN SuccessThis scenario illustrates successful MDN-Based subscription validation when the Serving MSCdetermines the originating subscriber is eligible for special service treatment. In this case, thecall from the Serv

35、ice Platform to a Call Back number invokes a WIN trigger at the MSC/VLRand successful call delivery to the terminating party. Figure 2 Successful MDN-Based Validation with WIN Success.a. A mobile subscriber originates a call to a dedicated number, e.g., voice mail, from alandline phone. An ISUP IAM

36、message is sent to the Serving MSC.b. The Serving MSC receives the incoming call and determines that the dialed numbertranslates to a dedicated route to a service platform, e.g., voice mail system and an IAM issent to this system.c. The service platform is only aware of the MDN (mobile directory num

37、ber) of thesubscriber, e.g., the subscriber is required to enter their MDN in order to access theirmessages. The service platform initiates a new call , e.g., to a callback number, on behalfof the subscriber and a new IAM is sent to the Serving MSC with the calling party numberset to the MDN.QUALREQ

38、2 MDN, MSCID, MYTYP, QUALCODE, ServiceQRTqualreq2 AUTHPER, HLRID, MYTYP, Profile,abedMSC/VLR HLRPlatformIAM (CdPN=dedicated number)IAM CdPN=CallBack No., CgPN=MDN)ORREQ (Digits(dialed)=CallBack No., CgPN=MDN, TriggerType)IAM (CdPN=dedicated number)cfPSTNSYSACCTYPE, TRANSCAP(MIN, IMSI or both), ESNgh

39、IAM (CdPN=CallBack No., CgPN=MDN)WINSCPorreq (RoutingDigits=CallBack No., CgPN=MDN)X.S0004-350-E v1.0MDN-Based Validation123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960350-4d. The Serving MSC determines that originating validation is re

40、quired for the incoming calland searches the VLR for a record corresponding to the originating subscribers MDN. Inthis case, a corresponding record is not found. This results in MAP QualificationRequest2(QUALREQ2) INVOKE message being sent to the Originating MSs Home HLR to retrievethe subscribers p

41、rofile information including the MIN, IMSI or both.e. The HLR locates the subscribers record using the supplied MDN, performs its validationfunctions, and returns a qualreq2 with the subscribers profile information and MIN,IMSI or both and ESN to the requesting Serving VLR.f. A trigger in the MSC/VL

42、R causes the MSC/VLR to send an ORREQ INVOKE to the WINSCP to request call origination instructions.g. The WIN SCP returns an orreq RETURN RESULTwith routing digits.h. The Serving MSC delivers the call to the PSTN.X.S0004-350-E v1.012345678910111213141516171819202122232425262728293031323334353637383

43、9404142434445464748495051525354555657585960350-5 MDN-Based Validation2.3 Successful MDN-Based Validation with WIN Call FailureThis scenario illustrates successful MDN-Based subscription validation when the Serving MSCdetermines the originating subscriber is eligible for special service treatment. In

44、 this case, thecall from the Service Platform to a Call Back number invokes a WIN trigger at the MSC/VLRand call failure treatment. Figure 3 Successful MDN-Based Validation with WIN Interaction.a. A mobile subscriber originates a call to a dedicated number, e.g., voice mail, from alandline phone. An

45、 ISUP IAM message is sent to the Serving MSC.b. The Serving MSC receives the incoming call and determines that the dialed numbertranslates to a dedicated route to a service platform, e.g., voice mail system and an IAM issent to this system.c. The service platform is only aware of the MDN (mobile dir

46、ectory number) of thesubscriber, e.g., the subscriber is required to enter their MDN in order to access theirmessages. The service platform initiates a new call , e.g., to a callback number, on behalfof the subscriber and a new IAM is sent to the Serving MSC with the calling party numberset to the M

47、DN.QUALREQ2 MDN, MSCID, MYTYP, QUALCODE, ServiceQRTqualreq2 AUTHPER, HLRID, MYTYP, Profile,abedMSC/VLR HLRPlatformIAM (CdPN=dedicated number)IAM CdPN=CallBack No., CgPN=MDN)ORREQ (Digits(dialed)=CallBack No., CgPN=MDN, TriggerType)IAM (CdPN=dedicated number)cfPSTNSYSACCTYPE, TRANSCAP(MIN, IMSI or bo

48、th), ESNghCall Failure TreatmentWINSCPorreq (AccessDeniedReason, ActionCode)X.S0004-350-E v1.0MDN-Based Validation123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960350-6d. The Serving MSC determines that originating validation is required

49、for the incoming calland searches the VLR for a record corresponding to the originating subscribers MDN. Inthis case, a corresponding record is not found. This results in MAP QualificationRequest2(QUALREQ2) INVOKE message being sent to the Originating MSs Home HLR to retrievethe subscribers profile information including the MIN, IMSI or both.e. The HLR locates the subscribers record using the supplied MDN, performs its validationfunctions, and returns a qualreq2 with the subscribers profile information and MIN,IMSI or both and ESN to the requesting Serving