1、 TIA-41.330-E August 2012Mobile Application Part (MAP) - Voice Feature Scenarios: Password Call Acceptance/Selective Call Acceptance ANSI/TIA-41.330-E-2012 APPROVED: AUGUST 8, 2012 NOTICE TIA Engineering Standards and Publications are designed to serve the public interest through eliminating misunde
2、rstandings 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 such Standards and Publications shall not in any resp
3、ect 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, either domestically or internationally. Standards and
4、 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 adopting the Standard or Publication. This Standard does no
5、t 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 applicability of regulatory limitations before its use. (From Pr
6、oject No. SP-3-3590.330-RV5-A, 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 De
7、partment 2500 Wilson Boulevard 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
8、/standards/catalog/ All rights 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 por
9、tions of this document, please 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) th
10、ere is no assurance that the Document 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 th
11、e use of intellectual property 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 statemen
12、t from the holder thereof is requested, 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
13、, which are instead left to the 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 th
14、e Document or its contents. If 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), whet
15、her such reference consists of 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
16、; (ii) TIAs policy of encouragement 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 identificati
17、on to TIA of a claim of Essential 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
18、 of the Document. 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 PARTICULAR PURPOSE OR USE, ITS MERCHANTABILITY AND ITS NONINFRINGEMENT OF ANY THIRD PARTYS INTELLEC
19、TUAL 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 APPLICABLE STATUTE, RULE OR REGULATION, OR THE SAFETY OR HEALTH EFFECTS OF THE CONTENTS OR ANY PRODUCT OR
20、SERVICE REFERRED TO IN THE DOCUMENT 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 O
21、R CONSEQUENTIAL DAMAGES (INCLUDING 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 NEGATI
22、ON OF DAMAGES IS A FUNDAMENTAL 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-330-E v1.0 April 2008 Initial publication.X.S0004-330-E v1.01234567891011121314151617181920212223242526272
23、82930313233343536373839404142434445464748495051525354555657585960330-1 INTRODUCTION1 INTRODUCTIONUnless otherwise noted, the scenarios in this section depict features operating individually; i.e.,feature interactions are not considered unless specifically noted.Also, please note that the scenarios i
24、n this section do not include a complete listing of operationparameters, either in the figures or in the accompanying text descriptions. Parameters areincluded where they are deemed necessary to improve the understanding of the scenario. For acomplete description of the parameters associated with ea
25、ch operation, refer to Parts 540 and550.2 PASSWORD CALL ACCEPTANCEThis section depicts the interactions between network entities in various situations related toautomatic roaming and Password Call Acceptance (PCA). These scenarios are for illustrativepurposes only.2.1 PCA Demand Activation or De-Act
26、ivationThe information flows required for the demand activation or de-activation of PCA by anauthorized MS are described in Part 311 Section 2.1.2.2 PCA Variable Diversion Registration or De-RegistrationThe information flows required for the registration or de-registration of PCA variable diversionb
27、y an authorized MS are described in Part 311 Section 2.1.2.3 PCA Password Registration or De-RegistrationThe information flows required for the registration or de-registration of PCA variable numberby an authorized MS are described in Part 311 Section 2.1.X.S0004-330-E v1.0PASSWORD CALL ACCEPTANCE12
28、3456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960330-22.4 PCA Invocation with Call AcceptedThis scenario describes the invocation of PCA for an authorized MS, with the result being callacceptance.a. A call origination and the dialed MS addr
29、ess digits (i.e., directory number) are receivedby the Originating MSC.b. The Originating MSC sends a LOCREQ to the MSs HLR.The HLR determines from the MSs service profile that PCA is active; therefore, it initiates a user interaction session.c. The HLR sends a RUIDIR to the Originating MSC.d. On re
30、ceipt of the RUIDIR, the Originating MSC turns off the LOCREQ timer andprovides call treatment as indicated in the received message. In this case, the treatmentis to answer the call (i.e., connect the calling party to subsystem capable of userinteraction).Figure 1 PCA Invocation with Call Acceptedab
31、cdefghijklmnHLR MSC Serving System ruidir DGTSDIAL RUIDIR ANNLIST, DGTCC call origination VLRdigits ROUTREQ MSID LRT MSC LOCREQ DGTSDIAL answer call prompt for password confirmation call setup ROUTREQ MSID routreq TLDN locreq TERMLIST, REDIND, ANNLIST routreq TLDN TLDNAT RUDTOriginating System RRT L
32、RT RRT X.S0004-330-E v1.0123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960330-3 PASSWORD CALL ACCEPTANCEe. The Originating MSC prompts the user based on the information in the receivedRUIDIR, and wait for digits.f. The user responds with
33、its password digits.g. The Originating MSC sends a ruidir to the HLR, containing the digits dialed by theuser. The HLR checks the digits received against the PCA screening list for the calledMS. In this scenario, the password is matched with an entry in the list; therefore, thecall is allowed to pro
34、ceed.h. If the dialed MS address digits are assigned to a legitimate subscriber, the HLR sendsa ROUTREQ to the VLR where the MS is registered.i. The VLR then forwards the ROUTREQ to the current Serving MSC.j. In reaction to the ROUTREQ, the Serving MSC checks its internal data structures anddetermin
35、es that the MS is currently idle. The Serving MSC allocates a TLDN andreturns this information to the VLR in the routreq. k. The VLR sends the routreq to the HLR.l. When the routreq is received by the HLR, it returns a locreq to the OriginatingMSC. The locreq includes routing information in the form
36、 of the TerminationListparameter, along with an indication of the reason for extending the incoming call (i.e.,for CD) in the DMH_RedirectionIndicator parameter. It also may include anAnnouncementList parameter, containing a PCA confirmation announcement to beprovided to the calling party.m. The Ori
37、ginating MSC provides call treatment as indicated in the locreq. In this case,the treatment is to, optionally, provide a confirmation announcement.n. The Originating MSC establishes a voice path to the Serving MSC using existinginterconnection protocols (e.g. SS7) and the routing information specifi
38、ed in thelocreq.X.S0004-330-E v1.0PASSWORD CALL ACCEPTANCE123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960330-42.5 PCA Invocation with Call Accepted: Alternate ProcedureThis scenario describes an alternate procedure for the invocation of
39、 PCA for an authorized MS,with the result being call acceptance. Figure 2 PCA Invocation with Call Accepted: Alternate ProcedureabcdefghijklmnopqrstHLR VLR MSCVRU MSC Serving System Originating System call setup MSC call origination routreq TLDN(VRU) answer call ROUTREQ MSID, TERMTREAT, DGTSDEST loc
40、req TERMLIST, REDIND digits confirmation prompt for password REDREQ REDREASON=CallAccepted ROUTREQ MSIDtrunumreq TERMLIST, REDIND redreq call release call setup TRANUMREQ MSID, REDREASON=CallAccepted ROUTREQ MSIDroutreq TLDNroutreq TLDNLOCREQ DGTSDIAL RRTTLDNAT RRTLRTTLDNAT RRTTTNRT RDRTX.S0004-330-
41、E v1.0123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960330-5 PASSWORD CALL ACCEPTANCEa. A call origination and the dialed MS address digits (i.e., directory number) are receivedby the Originating MSC.b. The Originating MSC sends a LOCREQ
42、to the MSs HLR.c. The HLR determines from the MSs service profile that PCA is active; therefore, itsends a ROUTREQ to an associated Voice Response Unit (MSC-VRU), including thecalled MIN and an indication that a PCA dialog is requested.d. The MSC-VRU allocates a TLDN and returns it to the HLR in a r
43、outreq.e. When the routreq is received by the HLR, it returns a locreq to the OriginatingMSC. The locreq includes routing information in the form of the TerminationListparameter, along with an indication of the reason for extending the incoming call (i.e.,for PCA) in the DMH_RedirectionIndicator par
44、ameter.f. The Originating MSC provides call treatment as indicated in the locreq. In this case,the treatment is to establish a voice path to the MSC-VRU using existinginterconnection protocols (e.g. SS7) and the routing information specified in thelocreq.g-j. The calling party enters a dialog with t
45、he MSC-VRU that may include voice prompts and entry of responses through DTMF digits or spoken words. The dialog may be more complex than shown here, including retransmission of the password if necessary.k. The PCA dialog being successfully completed, the MSC-VRU initiates redirection bysending a RE
46、DREQ to the Originating MSC with the RedirectionReason set to CallAccepted.l. The Originating MSC sends a TRANUMREQ to the HLR requesting the routinginformation appropriate for the Call Accepted condition.m. The HLR sends a ROUTREQ to the VLR where the MS is registered.n. The VLR forwards the ROUTRE
47、Q to the current Serving MSC.o. In reaction to the ROUTREQ, the Serving MSC checks its internal data structures anddetermines that the MS is currently idle. The Serving MSC allocates a TLDN andreturns this information to the VLR in a routreq.p. The VLR sends the routreq to the HLR.q. The HLR sends a
48、 tranumreq to the Originating MSC, including the TLDN in theTerminationList parameter, along with an indication of the reason for extending theincoming call (i.e., for CD) in the DMH_RedirectionIndicator parameter.r. When the tranumreq is received from the HLR, the Originating MSC sends aredreq to t
49、he MSC-VRU.s. The Originating MSC releases the inter-MSC call.t. The Originating MSC initiates call setup to the TLDN.X.S0004-330-E v1.0PASSWORD CALL ACCEPTANCE123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960330-62.6 PCA Invocation with Call Refused to Tone or AnnouncementThis scenario describes the invocation of PCA for an authorized MS, with the result being callrefusal to a tone or announcement.a-f. Same as PCA, Section 2.4, Steps a-f.g. The Originating MSC sends a ruidir to t
