1、 TIA-41.321-E-1E (Addendum to TIA-41.321-E) August 2012Mobile Application Part (MAP) - Voice Feature Scenarios: Call Delivery ANSI/TIA-41.321-E-1E-2012 APPROVED: AUGUST 10, 2012 NOTICE TIA Engineering Standards and Publications are designed to serve the public interest through eliminating misunderst
2、andings 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 respect
3、 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 Pu
4、blications 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 not p
5、urport 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 Proje
6、ct No. SP-3-3590.321-RV5-AD1-E-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
7、 Department 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.
8、org/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
9、portions 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)
10、 there 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
11、 the 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 state
12、ment 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 conditi
13、ons, 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
14、 the 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), w
15、hether 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 Refere
16、nce; (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 identific
17、ation 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 conte
18、nts 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 INTEL
19、LECTUAL 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
20、OR 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, INCIDENTA
21、L OR 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 NEG
22、ATION 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. 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960iiREVISION HISTORYRevision Date Remar
23、ksX.S0004-321-E v1.0 January 2007 Initial publication.X.S0004-321-E v2.0 January 2009 Addition of sections: 1.13, 1.14, 1.15, 1.16 based on Miscellaneous Enhancements 10.0X.S0004-321-E v2.0123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960
24、321-1 Call Delivery1 Call DeliveryThis section depicts the interactions between network entities in various situations related toautomatic roaming and Call Delivery (CD). These scenarios are informative. 1.1 CD Demand Activation or De-ActivationFor a description of the demand activation or deactivat
25、ion of CD by an authorized MS, seePart 311 Section 2.1.1.2 CD Invocation to an Idle MS on Another MSCThis scenario describes call delivery to an MS that is outside the serving area of the MSC wherethe call originates. MSCs in the functional model described in NAM contain switching functionsX.S0004-3
26、21-E v2.0Call Delivery123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960321-2only and must interact with their associated HLR and VLR to obtain database information foran MS; in a real application, the HLR/VLR functions may be integrated w
27、ith the MSC.a. 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 to the HLR associated with the MS; thisassociation is made through the dialed MS address digits (which may not be the MIN).c. If the di
28、aled MS address digits are assigned to a legitimate subscriber, the HLR sendsa ROUTREQ to the VLR where the MS is registered.d. The VLR then forwards the ROUTREQ to the current Serving MSC. Note that the MSmay have roamed within the domain of the Serving VLR and reported its new locationto that VLR
29、(via the new Serving MSC); the Serving VLR may not have reported thischange in location to the HLR.In reaction to the ROUTREQ, the Serving MSC consults its internal data structures to determine if the MS is already engaged in a call on this MSC. In this scenario, since the MS is idle, we are assumin
30、g that the MS is not known to the Serving MSC.e. The Serving MSC may then obtain the service profile of the MS from its VLR bysending it a QUALREQ.Figure 1 CD Invocation to an Idle MS on Another MSC abcdefghijklMSC VLR HLR MSC call origination Serving System routreq TLDN Originating System ROUTREQ M
31、SID QUALREQ routreq TLDN LOCREQ DGTSDIAL call setup QUALREQ qualreq qualreq LRT RRT RRT TLDNAT QRT locreq TERMLIST, REDIND QRT LOCREQ DGTSDIAL X.S0004-321-E v2.0123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960321-3 Call DeliveryThis step
32、 can be eliminated if the service profile is obtained by the Serving MSC prior to the termination attempt (e.g., when the MS registers). Subsequent scenarios do not explicitly show this step; they assume that the Serving MSC either already has the profile available when the ROUTREQ arrives or obtain
33、s the profile in a manner similar to that shown here.f. If the MS is unknown to the VLR or if the information requested by the MSC is notavailable at the VLR, the VLR sends a QUALREQ to the HLR associated with the MS.g. The HLR sends a qualreq to the VLR.h. The VLR sends a qualreq to the Serving MSC
34、.i. The Serving MSC allocates a TLDN (Temporary Local Directory Number) and returnsthis information to the VLR in the routreq.j. The VLR sends the routreq to the HLR.k. When the routreq is received by the HLR, it returns a locreq to the OriginatingMSC. The locreq includes routing information in the
35、form of the TerminationListparameter, along with an indication of the reason for extending the incoming call (i.e.,for CD) in the DMH_RedirectionIndicator parameter.l. The Originating MSC establishes a voice path to the Serving MSC using existinginterconnection protocols (e.g. SS7) and the routing i
36、nformation specified in thelocreq.X.S0004-321-E v2.0Call Delivery123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960321-41.3 CD Invocation to an Idle, Local MSThis scenario describes CD invocation to an idle MS that is served by the MSC whe
37、re the calloriginates. a. 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 to the HLR associated with the MS; thisassociation is made through the dialed MS address digits (which may not be the MIN).c
38、. If the dialed MS address digits are assigned to a legitimate subscriber and the HLRdetermines that the subscriber is currently served by the Originating MSC, the HLRsends a locreq to the Originating MSC.d. The Originating MSC, recognizing itself as the Serving MSC via the MSCIDparameter contained
39、in the TerminationList parameter, then attempts to terminate thecall to the MS identified in the locreq.Figure 2 CD Invocation to an Idle, Local MSabcdMSC MS HLR Originating SystemLOCREQ DGTSDIAL call termination call origination locreq TERMLIST, REDIND LRT X.S0004-321-E v2.0123456789101112131415161
40、718192021222324252627282930313233343536373839404142434445464748495051525354555657585960321-5 Call Delivery1.4 CD Invocation to a Busy MSThis scenario describes CD invocation to an MS that is busy in a call outside of the serving areawhere the call originates.a-d. Same as CD, see Part 321, sec. 1.2,
41、Steps a-d.e. In reaction to the ROUTREQ, the Serving MSC checks its internal data structures anddetermines that the MS is busy in another call. The status of the MS is returned to theVLR by the Serving MSC via the AccessDeniedReason parameter in the routreq.1f. The VLR sends the routreq to the HLR.g
42、. The HLR returns the busy status to the Originating MSC in the locreq.h. The Originating MSC then returns a busy indication to the calling party.Figure 3 CD Invocation to a Busy MS1In some environments it may be necessary to return a TLDN in addition to, or in place of, the MS status.Handling of th
43、ese situations is not illustrated by the above figure.abcdefghMSC VLR HLR MSC call origination Serving System ROUTREQ MSID locreq ACCDEN=Busy Originating System ROUTREQ MSID routreq ACCDEN=Busy LOCREQ DGTSDIAL busy indication routreq ACCDEN=Busy LRT RRT RRT X.S0004-321-E v2.0Call Delivery12345678910
44、1112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960321-61.5 CD Invocation with No Page Response or No AnswerThis scenario describes CD invocation to an MS when no page response or no answer isreceived by the Serving MSC after TLDN call arrival.a-d. Sa
45、me as CD, see Part 321, sec. 1.2, Steps a-d.e-h. Same as CD, see Part 321, sec. 1.2, Steps i-l, respectively.i. Either the MS fails to respond to the page or does not answer after alerting.j. The Serving MSC routes the call to an appropriate tone or announcement.k. The call is then disconnected usin
46、g the protocols defined by the interconnectionmethod.Figure 4 CD Invocation with No Page Response or No AnswerabcdefghijkMSC VLR HLR MSC call origination Serving System ROUTREQ MSID locreq TERMLIST, REDIND Originating System ROUTREQ MSID routreq TLDN LOCREQ DGTSDIAL call setuproutreq TLDN page or an
47、swer timeout announcement call release call release LRT RRT RRT X.S0004-321-E v2.0123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960321-7 Call Delivery1.6 CD Invocation to an Inaccessible MSThis scenario describes CD invocation to an MS th
48、at is inaccessible due to: CD inactive, MS inactive MS unregistered.a-b. Same as CD, see Part 321, sec. 1.2, Steps a-b.c. The HLR determines that the MS is not accessible (e.g., CD is inactive, MS is inactive,or MS is not registered). The HLR returns a locreq to the Originating MSC includingthe reas
49、on for denying access in the AccessDeniedReason parameter.d. The Originating MSC provides treatment to the served MS as implied by theAccessDeniedReason parameter and, if present, the AnnouncementList parameter. Inthis case, the treatment is to provide call refusal treatment.e. The Originating MSC releases the call.Figure 5 CD Invocation to an Inaccessible MSabcdeMSC HLR Originating SystemLOCREQ DGTSDIAL call refusal treatment locreq ACCDEN, ANNLIST call origination call release LRT X.S0004-321-E v2.0Call Delivery1234567891
