ANSI TIA-41.321-E-2007 Mobile Application Part (MAP) C Voice Feature Scenarios Call Delivery《移动应用部分(MAP).声音特点想定 呼叫转移》.pdf

1、TIA-41.321-E September 2007Mobile Application Part (MAP) Voice Feature Scenarios: Call Delivery ANSI/TIA-41.321-E-2007 APPROVED: JULY 11, 2007 REAFFIRMED: JANUARY 10, 2013 NOTICE TIA Engineering Standards and Publications are designed to serve the public interest through eliminating misunderstanding

2、s 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 precl

3、ude 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 Publicat

4、ions 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 purport

5、 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 Project No.

6、 3-3590.321-RV5-RF1, formulated under the cognizance of the TIA TR-45 Mobile (b) 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 a

7、ny editing process. 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, owned by one or more parties. TIA makes no search or investigation for IPR. When IPR consisting of patents and publish

8、ed pending 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 reference to, and disclaims any obligation to investigate or inquire into, the scope or validity of any claims of I

9、PR. TIA will neither be a party to discussions of any licensing terms or conditions, 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 p

10、ractices suggested or provided in the Manual have been complied with as respects 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 (

11、whether designated as a standard, specification, recommendation or otherwise), whether 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

12、 other SSO for IPR or letters of assurance relating to any such Normative Reference; (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 IP

13、R in the records or publications of the other SSO shall not constitute identification 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 inve

14、stigate products, designs or services or any claims of compliance with the contents 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 PURPO

15、SE OR USE, ITS MERCHANTABILITY AND ITS NONINFRINGEMENT 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 APPLICABLE STATUTE, RUL

16、E OR REGULATION, OR THE SAFETY OR HEALTH EFFECTS OF THE CONTENTS OR ANY PRODUCT 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 CONTAIN

17、ED HEREIN, INCLUDING WITHOUT LIMITATION ANY AND ALL INDIRECT, SPECIAL, INCIDENTAL 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

18、OTHERWISE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THE FOREGOING NEGATION 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. TIA-41.321-EMobile Application Part (MAP) - Voice Feature Scenarios:

19、 Call DeliveryREVISION HISTORYCopyright Telecommunications Industry Association 2007. All rights reserved.This document is subject to change.Revision Date RemarksTIA-41.321-E January 2007 Initial publication.TIA-41.321-EiiThis page is left blank intentionally.TIA-41.321-E1234567891011121314151617181

20、92021222324252627282930313233343536373839404142434445464748495051525354555657585960321-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

21、Activation or De-ActivationFor a description of the demand activation or deactivation 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.

22、MSCs in the functional model described in NAM contain switching functionsTIA-41.321-ECall Delivery123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960321-2only and must interact with their associated HLR and VLR to obtain database informatio

23、n foran MS; in a real application, the HLR/VLR functions may be integrated with 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

24、through the dialed MS address digits (which may not be the MIN).c. If the dialed 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 wi

25、thin the domain of the Serving VLR and reported its new locationto that VLR (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 i

26、n a call on this MSC. In this scenario, since the MS is idle, we are assuming 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 abcdefghijklMSCVLRHLR MSC

27、call origination Serving System routreq TLDN Originating System ROUTREQ MSID QUALREQ routreq TLDN LOCREQ DGTSDIAL call setup QUALREQ qualreq qualreq LRT RRT RRTTLDNAT QRTlocreq TERMLIST, REDIND QRTLOCREQ DGTSDIAL TIA-41.321-E123456789101112131415161718192021222324252627282930313233343536373839404142

28、434445464748495051525354555657585960321-3 Call DeliveryThis step 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 alre

29、ady has the profile available when the ROUTREQ arrives or obtains 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

30、qualreq to the VLR.h. The VLR sends a qualreq to the Serving MSC.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

31、 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 CD) in the DMH_RedirectionIndicator parameter.l. The Originating MSC establishes a voice path to the Serving MSC usin

32、g existinginterconnection protocols (e.g. SS7) and the routing information specified in thelocreq.TIA-41.321-ECall Delivery123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960321-41.3 CD Invocation to an Idle, Local MSThis scenario describes

33、 CD invocation to an idle MS that is served by the MSC where 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

34、the dialed MS address digits (which may not be the MIN).c. 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 it

35、self as the Serving MSC via the MSCIDparameter contained 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 HLROriginating SystemLOCREQ DGTSDIAL call termination call origination locreq TERMLIS

36、T, REDIND LRTTIA-41.321-E123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960321-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 ori

37、ginates.a-d. Same as CD, see Part 321, sec. 1.2, 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 r

38、outreq.1f. The VLR sends the routreq to the HLR.g. 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

39、 to, or in place of, the MS status.Handling of these situations is not illustrated by the above figure.abcdefghMSCVLR 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 RR

40、TRRT TIA-41.321-ECall Delivery123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960321-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 Se

41、rving MSC after TLDN call arrival.a-d. Same 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 announcem

42、ent.k. The call is then disconnected using the protocols defined by the interconnectionmethod.Figure 4 CD Invocation with No Page Response or No AnswerabcdefghijkMSCVLR HLR MSC call origination Serving System ROUTREQ MSID locreq TERMLIST, REDIND Originating System ROUTREQ MSID routreq TLDN LOCREQ DG

43、TSDIAL call setuproutreq TLDN page or answer timeoutannouncementcall release call release LRT RRT RRT TIA-41.321-E123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960321-7 Call Delivery1.6 CD Invocation to an Inaccessible MSThis scenario des

44、cribes CD invocation to an MS that 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 O

45、riginating MSC includingthe reason 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 tr

46、eatment.e. The Originating MSC releases the call.Figure 5 CD Invocation to an Inaccessible MSabcdeMSC HLROriginating SystemLOCREQ DGTSDIAL call refusal treatment locreq ACCDEN, ANNLIST call origination call release LRT TIA-41.321-ECall Delivery12345678910111213141516171819202122232425262728293031323

47、3343536373839404142434445464748495051525354555657585960321-81.7 CD Invocation with Intersystem PagingThis scenario describes CD invocation involving intersystem paging from the serving system toborder systems. Intersystem paging may help overcome location uncertainties in border systemTIA-41.321-E12

48、3456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960321-9 Call Deliveryareas allowing paging to be performed in border systems and by performing call routing towardsthe system where the subscriber is found.a-d. Same as CD, see Part 321, sec. 1

49、.2, Steps a-d.e-f. Before initiating local paging, at the time of local page initiation or after first page time-out, the Serving MSC may send an ISPAGE to one or more bordering MSCs according to its “topographical map” with a parameter indicating an area where the Figure 6 CD Invocation with Intersystem PagingabcdefghijklmnopqrstuvwxMSC VLR VLR MSCOriginating System Border System HLR MSC call origination LOCREQ DGTSDIAL ISPAGE PageIndicator QUALREQ ispage TLDN, EXTMSCID(Border) ROUTREQ MSID page request QUALREQ q