1、 TIA-41.400-E (Revision of TIA/EIA-41-D) December 2005Mobile Application Part (MAP)- Operations, Administration and Maintenance (OA (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
2、, modified or changed in the standards development or 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 investigat
3、ion for IPR. When IPR consisting of patents and published 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
4、 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, 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.
5、 TIA does not warrant or represent that procedures or 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
6、 formulation, development or publication of standards (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
7、 obligation to search or investigate the records of any 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 application
8、s shall apply; and (iii) Information as to claims of IPR 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
9、. TIA does not certify, inspect, test or otherwise investigate 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
10、, ITS FITNESS OR APPROPRIATENESS FOR A PARTICULAR PURPOSE 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 T
11、HE CONTENTS COMPLIANCE WITH ANY APPLICABLE STATUTE, RULE 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, ARIS
12、ING FROM OR RELATING TO ANY USE OF THE CONTENTS CONTAINED 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 WARRA
13、NTY, TORT (INCLUDING NEGLIGENCE), PRODUCT LIABILITY OR 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. REVISION HIST
14、ORY Copyright Telecommunications Industry Association 2005, All rights reserved.This document is subject to change.Revision Date RemarksIS-41-D December 1997 Initial ANSI publication.TIA-41.400-E July 2005 Initial publication with new part structure.TIA-41.000-E12345678910111213141516171819202122232
15、4252627282930313233343536373839404142434445464748495051525354555657585960400 -1 Operations, Administration and Maintenance(OA2) on receipt of the Blocking INVOKE after sending a FacilitiesDirective orFacilitiesDirective2 INVOKE or InterSystem Setup INVOKE and before any backwardmessage has been rece
16、ived;3) on receipt of a ResetCircuit INVOKE after sending a FacilitiesDirective orFacilitiesDirective2 INVOKE or InterSystem Setup INVOKE and before any backwardmessage has been received.1.2.2 Blocking and Unblocking of CircuitsThe Blocking (Unblocking) INVOKE is provided to permit the switching equ
17、ipment maintenancepersonnel to remove from (and return to) traffic the distant terminal of a circuit because of fault orto permit testing.The Blocking INVOKE can be originated by either MSC, since the circuits have bi-directionalcapability. The receipt of a Blocking INVOKE shall have the effect of p
18、rohibiting calls on therelevant circuit outgoing from the MSC until an Unblocking INVOKE is received, but shall notprohibit calls incoming to that MSC. Furthermore, receipt of a Blocking or Unblocking INVOKEshall not disrupt a handoff or trunk test that is already established on the circuit. Acknowl
19、edgmentsequences are always required for the Blocking and Unblocking INVOKEs using the BlockingRETURN RESULT and the Unblocking RETURN RESULT, respectively. The RETURN RESULTis not sent until the appropriate action, either Blocking or Unblocking has been taken. TheTIA-41.000-ENETWORK FEATURES1234567
20、89101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960400 -2FacilitiesRelease INVOKE should not override the Blocking INVOKE and return circuits to servicewhich might be faulty. The blocked circuit shall be returned to service on transmission of theU
21、nblocking RETURN RESULT at one MSC and on receipt of the Unblocking RETURN RESULTat the other MSC.1.2.3 Blocking StatesNOTE:Either MSC can initiate a trunk test in any of the above states. Blocking does not affect trunk tests.Also, an MSC can send a FacilitiesDirective, FacilitiesDirective2 INVOKE o
22、r an InterSystemSetupINVOKE for a circuit in the Locally Blocked state, but both the Near MSC (which is LocallyBlocked) and Far MSC (which is Remotely Blocked) should change the blocking state of the relevantcircuit to Active.1.2.4 State Transitions1. If an MSC has a circuit in the state Active, the
23、n:1i. Sending a Blocking INVOKE for the circuit causes a state change to Locally Blocked.ii. Receiving a Blocking INVOKE for the circuit causes a state change to RemotelyBlocked. (A Blocking RETURN RESULT should also be sent back.)iii. Receiving a Blocking RETURN RESULT for the circuit is not valid.
24、iv. Sending an Unblocking INVOKE for the circuit causes no state change.v. Receiving an Unblocking INVOKE for the circuit causes no state change. (AnUnblocking RETURN RESULT should also be sent back.)vi. Receiving an Unblocking RETURN RESULT for the circuit causes no state change.vii. Sending a Rese
25、tCircuit INVOKE for the circuit causes no state change.viii. Receiving a ResetCircuit INVOKE for the circuit causes no state change. (AResetCircuit RETURN RESULT should also be sent back with a trunk status of idle.)Table 1 Blocking StatesBlocking State Symbol MeaningActive ACT Indicating that the c
26、ircuit can be used by the Near MSC or the Far MSC.Remotely Blocked RB Indicating that the Near MSC has received a request from the Far MSC to not seize that circuit.Locally Blocked LB Indicating that the Near MSC has requested the Far MSC to not seize that circuit.Locally and Remotely BlockedLRB Ind
27、icating that the circuit cannot be used by the Near MSC or the Far MSC.1see Part 400, sec. 1.2.6TIA-41.000-E123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960400 -3 NETWORK FEATURESix. Sending a ResetCircuit RETURN RESULT with a trunk stat
28、us of blocked is notallowed in the state Active.x. Receiving a ResetCircuit RETURN RESULT with a trunk status of blocked causes astate change to Remotely Blocked.xi. Receiving a ResetCircuit RETURN RESULT with a trunk status of idle causes no statechange.xii. Sending a FacilitiesDirective or Facilit
29、iesDirective2 INVOKE for the circuit causes nostate change.xiii. Receiving a FacilitiesDirective or FacilitiesDirective2 INVOKE for the circuit causesno state change. (A FacilitiesDirective or FacilitiesDirective2 RETURN RESULTshould also be sent back.)xiv. Receiving a FacilitiesDirective or Facilit
30、iesDirective2 RETURN RESULT for thecircuit causes no state change.xv. Sending an InterSystemSetup INVOKE for the circuit causes no state change.xvi. Receiving an InterSystemSetup INVOKE for the circuit causes no state change. (AnInterSystemSetup RETURN RESULT should also be sent back.)xvii. Receivin
31、g an InterSystemSetup RETURN RESULT for the circuit causes no statechange.2. If an MSC has a circuit in the state Remotely Blocked, then:i. Sending a Blocking INVOKE for the circuit causes a state change to Locally andRemotely Blocked.ii. Receiving a Blocking INVOKE for the circuit causes no state c
32、hange. (A BlockingRETURN RESULT should also be sent back.)iii. Receiving a Blocking RETURN RESULT for the circuit is not valid.iv. Sending an Unblocking INVOKE for the circuit causes no state change.v. Receiving an Unblocking INVOKE for the circuit causes a state change to Active. (AnUnblocking RETU
33、RN RESULT should also be sent back.)vi. Receiving an Unblocking RETURN RESULT for the circuit causes no state change.vii. Sending a ResetCircuit INVOKE for the circuit causes no state change.viii. Receiving a ResetCircuit INVOKE for the circuit causes a state change to Active. (AResetCircuit RETURN
34、RESULT should also be sent back with a trunk status of idle.)ix. Sending a ResetCircuit RETURN RESULT with a trunk status of blocked is notallowed in the state Remotely Blocked.x. Receiving a ResetCircuit RETURN RESULT with a trunk status of blocked causes nostate change.xi. Receiving a ResetCircuit
35、 RETURN RESULT with a trunk status of idle causes a statechange to Active.xii. Sending a FacilitiesDirective or FacilitiesDirective2 INVOKE for the circuit is notallowed.TIA-41.000-ENETWORK FEATURES123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555
36、657585960400 -4xiii. Receiving a FacilitiesDirective or FacilitiesDirective2 INVOKE for the circuit causesa state change to Active. (A FacilitiesDirective or FacilitiesDirective2 RETURNRESULT should also be sent back.)xiv. Receiving a FacilitiesDirective or FacilitiesDirective2 RETURN RESULT for the
37、circuit is not valid.xv. Sending an InterSystemSetup INVOKE for the circuit is not allowed.xvi. Receiving an InterSystemSetup INVOKE for the circuit causes a state change toActive. (An InterSystemSetup RETURN RESULT should also be sent back.)xvii. Receiving an InterSystemSetup RETURN RESULT for the
38、circuit is not valid.3. If an MSC has a circuit in the state Locally Blocked, then:i. Sending a Blocking INVOKE for the circuit causes no state change.ii. Receiving a Blocking INVOKE for the circuit causes a state change to Locally andRemotely Blocked. (A Blocking RETURN RESULT should also be sent b
39、ack.)iii. Receiving a Blocking RETURN RESULT for the circuit causes no state change.iv. Sending an Unblocking INVOKE for the circuit causes a state change to Active.v. Receiving an Unblocking INVOKE for the circuit causes no state change. (AnUnblocking RETURN RESULT should also be sent back.)vi. Rec
40、eiving an Unblocking RETURN RESULT for the circuit is not valid.vii. Sending a ResetCircuit INVOKE for the circuit causes a state change to Active.viii. Receiving a ResetCircuit INVOKE for the circuit causes no state change. (AResetCircuit RETURN RESULT with a trunk status of blocked should also be
41、sentback.)ix. Sending a ResetCircuit RETURN RESULT with a trunk status of idle is not allowedin Locally Blocked.x. Receiving a ResetCircuit RETURN RESULT for the circuit is not valid.xi. Sending a FacilitiesDirective or FacilitiesDirective2 INVOKE for the circuit causes astate change to Active.xii.
42、Receiving a FacilitiesDirective or FacilitiesDirective2 INVOKE for the circuit causesno state change. (A FacilitiesDirective or FacilitiesDirective2 RETURN ERRORshould also be sent back.)xiii. Receiving a FacilitiesDirective or FacilitiesDirective2 RETURN RESULT for thecircuit is not valid.xiv. Send
43、ing an InterSystemSetup INVOKE for the circuit causes a state change to Active.xv. Receiving an InterSystemSetup INVOKE for the circuit causes no state change. (AnInterSystemSetup RETURN ERROR should also be sent back.)xvi. Receiving an InterSystemSetup RETURN RESULT for the circuit is not valid.4.
44、If an MSC has a circuit in the state Locally and Remotely Blocked, then:TIA-41.000-E123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960400 -5 NETWORK FEATURESi. Sending a Blocking INVOKE for the circuit causes no state change.ii. Receiving
45、a Blocking INVOKE for the circuit causes no state change. (A BlockingRETURN RESULT should also be sent back.)iii. Receiving a Blocking RETURN RESULT for the circuit causes no state change.iv. Sending an Unblocking INVOKE for the circuit causes a state change to RemotelyBlocked.v. Receiving an Unbloc
46、king INVOKE for the circuit causes a state change to LocallyBlocked. (An Unblocking RETURN RESULT should also be sent back.)vi. Receiving an Unblocking RETURN RESULT for the circuit is not valid.vii. Sending a ResetCircuit INVOKE for the circuit causes a state change to RemotelyBlocked.viii. Receivi
47、ng a ResetCircuit INVOKE for the circuit causes a state change to LocallyBlocked. (A ResetCircuit RETURN RESULT with a trunk status of blocked shouldalso be sent back.)ix. Sending a ResetCircuit RETURN RESULT with a trunk status of idle is not allowedin Locally and Remotely Blocked.x. Receiving a Re
48、setCircuit RETURN RESULT for the circuit is not valid.xi. Sending a FacilitiesDirective or FacilitiesDirective2 INVOKE for the circuit is notallowed.xii. Receiving a FacilitiesDirective or FacilitiesDirective2 INVOKE for the circuit causesa state change to Locally Blocked. (A FacilitiesDirective or
49、FacilitiesDirective2RETURN ERROR should also be sent back.)xiii. Receiving a FacilitiesDirective or FacilitiesDirective2 RETURN RESULT for thecircuit is not valid.xiv. Sending an InterSystemSetup INVOKE for the circuit is not allowed.xv. Receiving an InterSystemSetup INVOKE for the circuit causes a state change toLocally Blocked. (An InterSystemSetup RETURN ERROR should also be sent back.)xvi. Receiving an InterSystemSetup RETURN RESULT for the circuit is not valid.1.2.5 Other Actions on Receipt of a Blocking INVOKEIn the event of the receipt of a Blocking INVOKE:1) after a FacilitiesDire
