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

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

2、gs 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 prec

3、lude 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 Publica

4、tions 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 purpor

5、t 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.322-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

7、any 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 publis

8、hed 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

9、IPR. 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

10、practices 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 an

12、y 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 I

13、PR 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 inv

14、estigate 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 PURP

15、OSE 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, RU

16、LE 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 CONTAI

17、NED 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.322-EMobile Application Part (MAP) - Voice Feature Scenarios

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

20、18192021222324252627282930313233343536373839404142434445464748495051525354555657585960322-1 INTRODUCTION1 INTRODUCTIONUnless otherwise noted, the scenarios in this Part depict features operating individually; i.e.,feature interactions are not considered unless specifically noted.The scenarios in thi

21、s Part do not include a complete listing of operation 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 opera

22、tion, refer to Parts-540 and -550.2 Call ForwardingBusyThis section depicts the interactions between network entities in various situations related toautomatic roaming and Call ForwardingBusy (CFB). These scenarios are for illustrativepurposes only.2.1 CFB Variable Registration or De-RegistrationThe

23、 information flows required for the registration or de-registration of CFB by an authorizedMS are described in Part-311 Section 2.1.2.2 CFB Demand Activation with Courtesy CallThe information flows required for the demand activation of CFB by an authorized MS, wherethe serving system provides the op

24、tional courtesy call to the forward-to number on CFBactivation, are described in Part-311 Section 2.2.2.3 CFB Demand Activation (without Courtesy Call) or De-ActivationThe information flows required for the demand activation or de-activation of CFB by anauthorized MS, where the serving system does n

25、ot provide the optional courtesy call to theforward-to number on CFB activation, are described in Part-311 Section 2.1.TIA-41.322-ECall ForwardingBusy123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960322322-22.4 CFB InvocationThis scenario

26、 describes CFB invocation due to the served MS being busy.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

27、digits (which might not be the sameas 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.e. In reaction to the ROUTREQ, the Serving MSC check

28、s 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 in the routreq.f. The VLR sends the routreq to the HLR.g. The HLR determines from the service profile that CFB is active. It sends a locreqto the Originatin

29、g MSC providing the forward-to number and other routinginformation in the TerminationList parameter, along with an indication of the reasonfor extending the incoming call (i.e., for CFB) in the DMH_RedirectionIndicatorparameter.h. The Originating MSC then establishes a call to the specified forward-

30、to number.Figure 1 CFB InvocationabcdefghMSCVLRHLRMSCcall origination Serving System ROUTREQ MSID locreq TERMLIST, REDIND Originating System ROUTREQ MSID LOCREQ DGTSDIAL call forward setup routreq ACCDEN=Busy LRT RRT routreq ACCDEN=Busy RRTTIA-41.322-E123456789101112131415161718192021222324252627282

31、930313233343536373839404142434445464748495051525354555657585960322-3 Call ForwardingBusy2.5 CFB Invocation with Call CollisionThis scenario describes call delivery to a MS that has CFB active and becomes engaged in a callat the same time that the Originating MSC is delivering a call to the Serving M

32、SC. a-d. Same as CFB, Section 2.4, Steps a-d.e. The Serving MSC allocates a TLDN (Temporary Local Directory Number) and returnsthis information to the VLR in the routreq.f. The VLR sends the routreq to the HLR.g. When the routreq is received by the HLR, it returns a locreq to the OriginatingMSC. The

33、 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.Figure 2 CFB Invocation with Call CollisionabcdefghijklmnoMSCVLRHLRMSCcall origination Serv

34、ing System ROUTREQ MSID locreq TERMLIST, REDIND Originating System ROUTREQ MSID routreq TLDN LOCREQ DGTSDIAL call setup routreq TLDN MS becomes busyREDREQ REDREASON=Busy redreq TRANUMREQ REDREASON=Busy tranumreq TERMLIST, REDIND call release LRTRRT RRT TTNRT RDRTcall forward setup TIA-41.322-ECall F

35、orwardingBusy123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960322322-4h. Sometime after the Serving MSC sends the routreq back to the HLR, the MSbecomes engaged in another call. This may be the result of an MS origination, a callthrough t

36、he local roamer port or the arrival of an inter-MSC call from a previousROUTREQ.i. Upon receiving the locreq, the Originating MSC sets up a voice path to the ServingMSC using the protocols defined by the interconnection method.When the inter-MSC call is received, the Serving MSC checks its internal

37、data struc-tures and determines that the MS is busy in another call. The Serving MSC determines from the service profile that the MS has call forwarding on busy active.j. The Serving MSC then sends a REDREQ to the Originating MSC, indicating that thecall is being redirected due to a “busy” condition

38、.k. The Originating MSC is able to redirect the call, therefore, it sends a TRANUMREQ tothe HLR requesting the forward-to number appropriate for this condition from theMSs service profile.l. The HLR sends the tranumreq to the Originating MSC, including the appropriateforward-to number in the Termina

39、tionList parameter, along with an indication of thereason for extending the incoming call (i.e., for CFB) in theDMH_RedirectionIndicator parameter.m. When the tranumreq is received from the HLR, the Originating MSC sends aredreq to the Serving MSC.n. The Originating MSC releases the voice path to th

40、e Serving MSC.o. The Originating MSC initiates call forwarding using the specified forward-to number.TIA-41.322-E123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960322-5 Call ForwardingDefault3 Call ForwardingDefaultThis section depicts the

41、 interactions between network entities in various situations related toautomatic roaming and Call ForwardingDefault (CFD). These scenarios are for illustrativepurposes only.3.1 CFD Variable Registration or De-Registration The information flows required for the registration or de-registration of CFD

42、by an authorizedMS are described in Part-311 Section 2.1.3.2 CFD Demand Activation with Courtesy Call The information flows required for the demand activation of CFD by an authorized MS, wherethe serving system provides the optional courtesy call to the forward-to number on CFDactivation, are descri

43、bed in Part-311 Section 2.2.Note that the activation of CFD results in the activation of call forwarding on busy, no answer,and no page response conditions at the Serving MSC.3.3 CFD Demand Activation (without Courtesy Call) or De-Activation The information flows required for the demand activation o

44、r de-activation of CFD by anauthorized MS, where the serving system does not provide the optional courtesy call to theforward-to number on CFD activation, are described in Part-311 Section 2.1.Note that the activation of CFD results in the activation of call forwarding on busy, no answer,and no page

45、 response conditions at the Serving MSC. Likewise, the de-activation of CFD mayresult in the de-activation of call forwarding on busy (if CFB is not active), no answer (if CFNAis not active), and no page response (if CFNA is not active) conditions at the Serving MSC.3.4 CFD Invocation with BusyThe i

46、nformation flows required for the invocation of CFD when the served MS is determinedto be busy are the same as those for the CFB case described in Section 2.4; simply replace theacronym CFB in that description with CFD.3.5 CFD Invocation with Call CollisionThe information flows required for the invo

47、cation of CFD when the served MS becomesengaged in a call at the same time that the Originating MSC is delivering a call to the ServingMSC, are the same as those for the CFB case described in Section 2.5; simply replace theacronym CFB in that description with CFD.TIA-41.322-ECall ForwardingDefault12

48、3456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960322322-63.6 CFD InvocationImmediateThis scenario describes CFD invocation due to the following causes: Do Not Disturb active, etc. MS not registered by MAP procedures. MS reported inactive by

49、 MAP procedures. Roaming with Call Delivery inactive.In these cases, the HLR has sufficient information available to make an immediate forwardingdecision, rather than directing that the call be routed to the serving system. 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. The HLR determines from the MSs se