1、 TIA-41.200-E July 2007Mobile Application Part (MAP) - Intersystem Handoff ANSI/TIA-41.200-E-2007 APPROVED: JULY 11, 2007 REAFFIRMED: DECEMBER 20, 2012 NOTICE TIA Engineering Standards and Publications are designed to serve the public interest through eliminating misunderstandings between manufactur
2、ers 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 no
3、n-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
4、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 to address all safe
5、ty 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. 3-3590.200-RV5-RF1,
6、 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 any editing process.
7、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 published pending patent ap
8、plications 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 IPR. TIA will neither
9、 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 practices suggested o
10、r 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 (whether designated a
11、s 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 other SSO for IPR o
12、r 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 IPR in the records or
13、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 investigate products, de
14、signs 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 PURPOSE OR USE, ITS MERCH
15、ANTABILITY 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, RULE OR REGULATION, OR
16、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 CONTAINED HEREIN, INCLUDING
17、 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 OTHERWISE, EVEN IF A
18、DVISED 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. Mobile Application Part (MAP) - Intersystem HandoffRevision HistoryCopyright Telecommuni
19、cations Industry Association 2006. All rights reserved.This document is subject to change.Revision Date RemarksTIA-41.200-E May 2006 Initial publication.TIA-41.200-E123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960200-1PART 2001 INTRODUCT
20、ION 1.1 OBJECTIVE1.2 OBJECTIVEThis specification presents the recommendation for the handoff sequence between two differentMobile Switching Centers (MSCs). This is often called intersystem handoff. To perform anintersystem handoff means to switch a Mobile Station (MS) telephone call that is in progr
21、ess on oneMSC, to a different MSC. In other words, an MS is assigned to a voice/traffic channel that iscontrolled by a different MSC. During an MS telephone call, the MSC that is the first to assign a traffic channel to a call onorigination or termination is called the Anchor MSC. For the duration o
22、f this call, this MSC shall bethe anchor (i.e., fixed) point in the event that the MS should be handed off to other MSCs. The MSCcontrolling the call is termed the Serving MSC. A neighbor MSC is called a candidate MSC if theneighbor is being considered as a possible server in a locate/handoff sequen
23、ce. A neighbor MSC iscalled a Target MSC if the neighbor has been chosen by the Serving MSC as the next Serving MSC,but the handoff has not yet occurred. A Serving MSC which has previously received a handoff caninitiate another handoff using the procedures appropriate to a Serving MSC, and thereby b
24、ecomes aTandem MSC.Intersystem handoff is used when two MSCs are adjacent to one another and the neighbor system isbetter able to serve an MS than the serving system. The neighbor system and the serving system musthave contiguous serving areas. It is assumed that MSCs may have information concerning
25、 theirneighboring MSCs capabilities that may effect how handoffs are performed and whether or nothandoffs are performed. Intersystem handoff is triggered by the locate operation or mobile assistedhandoff (MAHO). In the serving system, the neighbor system shall appear as a “neighbor” to theserving sy
26、stem cell sites that are adjacent to the neighbor system.1.3 SCOPEThis specification defines intersystem handoff by describing the information flows betweenfunctional entities which occur in a number of intersystem handoff scenarios.TIA-41.200-E2 BASIC INTERSYSTEM HANDOFF SCENARIOS123456789101112131
27、415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960200-22 BASIC INTERSYSTEM HANDOFF SCENARIOSThis section depicts the interactions between network entities in various situations related to thesupport of basic intersystem handoff functionality:Handoff-Forward
28、. The handoff of a call from Serving MSC to Target MSC, where the TargetMSC is not already on the call path (i.e., is not the Anchor or a tandem MSC) and pathminimization is not applied.Handoff-Back. The handoff of a call from Serving MSC to Target MSC, where the Target MSCis already on the call pat
29、h.Handoff-Forward with Tandem. The Handoff-Forward process when more than two MSCs areinvolved.Handoff-Back with Tandem. The Handoff-Back process when more than two MSCs areinvolved.Handoff-Back with Tandem via FacilitiesDirective (Path Minimization is not supported). TheHandoff-Back process when mo
30、re than two MSCs are involved but Path Minimization is notsupported.Handoff-Back with Tandem via FacilitiesDirective when HandoffToThird with Tandem andPath Minimization fails. The handoff of a call from Serving MSC to Target MSC, where theTarget MSC is already on the call path (that is, as an Ancho
31、r or a Tandem MSC) and pathminimization can not be supported.Handoff-To-Third with Path Minimization. The handoff of a call from Serving MSC to TargetMSC, where the Target MSC is not already on the call path (i.e., is not the Anchor or a tandemMSC) and path minimization is applied.Handoff-To-Third w
32、ith Tandem and Path Minimization. The Handoff-To-Third with PathMinimization process when more than two MSCs are involved.Handoff-Back with Tandem via HandoffToThird when the method of HandoffToThird withTandem and Path Minimization is involved. The handoff of a call from Serving MSC to TargetMSC, w
33、here the Target MSC is already on the call path (that is, as an Anchor or a TandemMSC) and path minimization is applied.Call Release. The release of a call that had previously been handed-off. This can be initiated bythe served MS or the other party of the call.The FacilitiesDirective, HandoffBack,
34、HandoffMeasurementRequest, and HandoffToThirdoperations are used throughout this section; however, the FacilitiesDirective2, HandoffBack2,HandoffMeasurementRequest2, and HandoffToThird2 operations, respectively, may be substitutedfor these operations without impacting the scenarios as illustrated.TI
35、A-41.200-E123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960200-3 2.1 Successful Handoff-Forward2.1 Successful Handoff-ForwardThis scenario describes the successful Handoff-Forward process.Figure 1 Successful Handoff-Forwarda. A call invol
36、ving the served MS is in progress.abBXAcdefghiBXAhandmreqHANDMREQcall in progressFACDIRfacdirhandoff orderx arrives on new channelMSONCHhandoff completeAnchor therefore, the TargetMSC increases the Segment Counter in the received BillingID parameter by one and usesthe new BillingID for the new call
37、segment, returns a facdir to the requesting MSC, andinitiates a Handoff-Forward task.f. On receipt of the facdir, the Serving MSC sends a Mobile Handoff Order to the servedMS.g. The MS is received on the designated traffic channel; therefore, .h. .the Target MSC completes the voice path between the
38、traffic channel and the inter-MSCtrunk and sends a MSONCH to the initiator of the Handoff-Forward task, the Serving MSC,informing the requesting system that the Target MSC has successfully completed theHandoff-Forward task.i. The Serving MSC, on receipt of the MSONCH, completes the handoff process.
39、The inter-MSC trunk should be connected at this time if it has not already been connected.TIA-41.200-E123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960200-5 2.2 Successful Handoff-Back2.2 Successful Handoff-BackThis scenario describes the
40、 successful Handoff-Back process.Figure 2 Successful Handoff-Backa-c. Same as Section 2.1, Steps a-c.abBXAcdefghjBXAiMSC MSC MSAnchor therefore, the Target MSCincreases the Segment Counter in the received BillingID parameter by one and uses the newBillingID for the new call segment, returns a handba
41、ck to the requesting MSC, andinitiates a Handoff-Back task.f. The Serving MSC, on receipt of the handback, sends a Handoff Order to the served MS.g. The MS is received on the designated voice channel; therefore, .h. .the Target MSC sends a FACREL to the Serving MSC, indicating HandoffSuccessful.i. T
42、he Serving MSC sends a facrel to the Target MSC and marks the inter-MSC trunk asidle.j. The Target MSC marks the inter-MSC trunk as idle and the handoff-back process iscomplete.TIA-41.200-E123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960
43、200-7 2.3 Successful Handoff-Back with Tandem viaFacilitiesDirective (Path Minimization is notsupported)2.3 Successful Handoff-Back with Tandem via FacilitiesDirective (Path Minimization is not supported)Figure 3 Successful Handoff-Back with Tandem via FacilitiesDirective (Path Minimization is not s
44、upported)abBAcdefghAiCXXHANDMREQ handmreq FACDIR facdir MSONCHhandoff order x arrives on new channel call in progressAnchor Target System A Tandem System B Serving System C Served MS X MSC MSC MSC MS Initial ConnectionsRESPONSEQUERY w/PERMISSIONCONV w/PERMISSIONResulting ConnectionsHOT MHOTMAT LMMRT
45、 YYTCAP Package Type lhandoff - back complete FACRELFACRELFACRELfacrel facrel facrel kjmnoCTT CTT CTT TIA-41.200-E2.3 Successful Handoff-Back with Tandem via FacilitiesDirective (Path Minimization is not supported)12345678910111213141516171819202122232425262728293031323334353637383940414243444546474
46、8495051525354555657585960200-8a-c. Same as Section 2.1, Steps a-c.d. The Serving MSC determines that the call should be handed off to the candidate (nowTarget) MSC. It sends a FACDIR to the Target MSC, directing the Target MSC to initiatea Handoff-Forward task. If the Serving MSC counts tandem segme
47、nts, then it incrementsthe Segment Counter by one in the BillingID parameter.e. The necessary facilities on the designated Target MSC are available; therefore, the TargetMSC increases the Segment Counter in the received BillingID parameter by one and usesthe new BillingID for the new call segment. T
48、he Target MSC returns a facdir to therequesting MSC.f. On receipt of the facdir, the Serving MSC sends a Mobile Handoff Order to the servedMS.g. The MS is received on the designated traffic channel; therefore, .h. .the Target MSC completes the path between the traffic channel and the inter-MSC trunk
49、and sends a MSONCH to the initiator of the Handoff-Forward task.i. If the Target MSC had already an associated inter-MSC trunk with the MS (e.g. BillingIDor MSID is already used in the call, and therefore the Target MSC is also the Anchor orTandem MSC in the call path), then the Target MSC requests release of the inter-MSCtrunk to the previous Serving MSC. The Target MSC sends a FACREL via the call path,with the reason for release indicating HandoffSuccessful.j. The Tandem MSC forwards the FACREL toward the previous Serving MSC.k. The previous Serving MSC sends a FACREL to the previous
