导致ServiceChange命令发送的事件在本附件中描述如下：
1) MG注册 — MG向MGC注册并建立控制联系。
2) MG重新注册—当MG被MGC要求注册时，MG重新向MGC注册。
3) MG业务取消 — MG通知MGC，作为一个整体的终结点或MG将退出业务。
4) MG业务恢复 — MG从故障中恢复并通知 MGC。
5) MG冗余切换 —出现故障或对主控 MG进行维护时，备用MG进行切换。
6) MG失去通信 — MG向MGC通告它先前与MGC失去通信但现在通信已经恢复了。
7) MG能力变化 — MG通知MGC，作为一个整体的MG或终结点的能力已经发生了变化。
8) MGC发起MG重新注册 — MGC通知MG，MG应该向同一MGC或其他MGC重新注册。
9) MGC发起业务恢复 — MGC从故障中恢复并命令MG将相关终结点置于初始状态。 10) MGC发起业务取消 — MGC通知MG，作为一个整体的MG或终结点将退出业务。 11) MGC故障冗余 —主控MGC故障并指示MG向特定的备用MGC注册。
图F.1阐明了这些ServiceChange触发事件，展示了事件中的实体和相关的事件对。图 F.2展示了MG和 MG上的终结点应该遵循的状态模型。
图片1
图片2
2 控制联系定义
控制联系是一种 MGC凭借控制 MG的通信关系。控制联系通过注册来实现。控制联系由于 MG退出业务而终止，也可以成功地转移到替代 MGC，或者成功地故障冗余至替代的 MGC。在任何时候， MG应最多具有一个控制联系，除非一个物理的 MG被分割为一个或多个虚拟 MG。仅仅是MG能够建立控制联系。这里所定义的控制联系仅仅适用于媒体网关控制信令中的关联。该定义不应与传送协议关联（例如 TCP、 UDP）里的控制联系相混淆。
在Root终结点上使用 ServiceChange命令仅仅影响 Root终结点所属的虚拟 MG。在同一物理 MG上的虚拟MG并不受影响。
- 3 导致ServiceChange程序的事件
- 3.1 MG注册
MG可以用下列三种方式之一进行注册：
- • 宣告其初始出现或“注册”，使用ServiceChangeReasons＝901（"Cold Boot"）或902（"Warm Boot"）的ServiceChangeMethod "Restart"，
- • 通过ServiceChangeMethod＝"Failover"和ServiceChangeReason＝909("MGC Impending Failure") 或 908 ("MG Impending Failure")来指示MG正在改变其控制联系，
- • 通过ServiceChangeMethod＝"Handoff"和ServiceChangeReason＝903 ("MGC Directed Change")
(3.11)来指示 MG被命令改变其控制联系。
当最初的 ServiceChange命令由MG发往MGC时，注册开始；当 MGC返回响应命令且该响应中没有替代的MGC地址或差错代码且ServiceChangeProfile在MGC和MG之间协商一致时，注册完成。一旦注册完成，则控制联系就建立了。注册总发生在 Root终结点上。一旦初始化新的注册，则在 MGC和MG之间的任何已有的控制联系将被终止。所有来自先前控制联系的命令都将被忽略。
注册消息使用ServiceChangeProfile，细节参见 5.5。注册消息使用ServiceChangeVersion，细节参见 5.6。
3.2 MG重新注册
| MG重新注册发生在两种情况下： | |
|---|---|
| 1) | 当 MGC要求 MG重新注册（ 3.8）时， MG应发送 ServiceChangeMethod＝ "Handoff"、 ServiceChangeReason＝ 903 ("MGC Directed Change")和指定 "ServiceChangeMgcID"的 ServiceChange。 |
| 2) | 当 MGC发起业务恢复（ 3.9）时， MG应通过发送 ServiceChangeMethod＝ "Restart"的 ServiceChange来注册。 |
| 当MGC返回响应命令且该响应中没有替代的 MGC地址或差错代码且 ServiceChangeProfile在MGC和 | |
MG之间协商一致时，重新注册完成。如果未能从主控 MGC接收到响应，则 MG应遵循 3.1的程序。建议采用ServiceChangeReasons＝903 ("MGC Directed Change")或909 ("MGC Impending Failure")的消息。
一旦完成注册，则控制联系就建立了。注册总是发生在Root终结点上。一旦初始化新的注册，则在 MGC和MG之间的任何已有的控制联系将被终止。所有来自先前控制联系的命令都将被忽略。
注册消息使用ServiceChangeProfile，细节参见 5.5。
注册消息使用ServiceChangeVersion，细节参见 5.6。
3.3 MG业务取消
为了将MG置于"OutOfService"状态， MG在Root终结点上发送 ServiceChangeMethod＝"Forced"或 "Graceful"的ServiceChange命令。细节参见4.1.1。
为了将一个终结点或一组终结点置于 "OutOfService"状态， MG在所请求的终结点上发送 ServiceChangeMethod＝"Forced"或"Graceful"的ServiceChange命令。细节参见 4.1.2和4.1.3。
ServiceChangeDelay指示业务取消将要发生之前的时间长度。细节参见5.3。
为了取消先前对整个 MG发出的（和已经确认的） Graceful事件，MG在Root终结点上发送 ServiceChangeMethod＝"Restart"和ServiceChangeReason＝918("Cancel Graceful")的ServiceChange命令。 MG将仍保持在 InService状态，而且先前设置成 OutOfService的所有终结点都返回业务态，除了那些被 MG告知的终结点外。在Delay定时器超时之后接收到Cancel Graceful的事件中，则 MG应必然进行重新注册，就如它发送Cold Boot事件一样。
为了取消先前发出的（和已经确认的）某个终结点或某组终结点上 Graceful事件， MG在所请求的终结点上发送 ServiceChangeMethod＝"Restart"和ServiceChangeReason＝"Cancel Graceful"的ServiceChange命令。终结点将仍保持在 InService状态。在终结点已经转移至 OutOfService状态的事件中，终结点应该返回至业务状态，就如它发送ServiceChange Restart事件一样。
3.4 MG业务恢复
当MG在故障或维护行为之后返回至业务时，将发生MG业务恢复事件。
当由MG发送消息时， MG相MGC发送ServiceChange命令来告知它已经重新启动或希望重新协商软件版本或H.248 Profile。在这种情况下使用 ServiceChangeMethod="Restart"h ServiceChangeReason=900 ("Service Restored")。ServiceChangeReason将指示MGC需要采取什么动作。
3.5 MG冗余切换
下列两种情况用于MG冗余切换：
- 1) 由主控MG发起的切换：
- 当 MG即将退出业务并希望将处理转交给指定的备用 MG，则 MG向 MGC发送 ServiceChangeMethod＝ "Failover"和 ServiceChangeReason＝ 908 ("MG Impending Failure")的 ServiceChange命令。 MGC将终止向主控 MG发送消息并终止控制联系。备用 MG将发送 ServiceChangeMethod＝"Restart"和ServiceChangeReason＝900 ("Service Restored")的ServiceChange命令。MGC将与备用MG建立新的控制联系。
- 2) 由备用MG发起的切换：
当可选的备用 MG检测到主控 MG进入维护期或故障期且主控 MG不能向MGC通告故障时，备用 MG向MGC发送ServiceChangeMethod＝"Failover"和ServiceChangeReason＝919 ("Warm Failover")或920 ("Cold Failover")的ServiceChange命令。采用3.4程序。
MGC应忽略任何由未知 MG发起的冗余切换尝试。通过预置或其他方式， MGC必须知道宣传冗余切换的备用MG是与故障的主控MG相关并授权认可对主控MG的切换。
如果备用MG是已知的且得到了对主控 MG的切换授权，则 MGC应尝试与主控 MG通信以确定该 MG是否仍然工作。这可以通过一个空的AuditValue命令或其他适当的方法（参见 11.5）来完成。如果主控 MG应答了，则 MGC将拒绝故障切换尝试。如果主控 MG无法应答，则 MGC将假定主控 MG已经发生故障了并接受warm或cold方式的故障切换。当 MGC接收warm或cold方式的故障切换，则与主控MG之间的控制联系被消除并建议与备用MG之间的新控制联系。
3.6 MG失去通信
当MG检测到与MGC失去通信并随后重新建立与MGC的通信，MG在当前的控制联系中向MGC发送 ServiceChangeMethod＝"Disconnected"的ServiceChange命令。如果 MGC未能响应， MG则按顺序向其列表中的每个MGC发送ServiceChangeMethod＝"Failover"和ServiceChangeReason＝909 ("MGC Impending Failure")的ServiceChange命令，直到成功地建立新的控制联系，否则MG将遍历其列表上的所有MGC。
如果最初控制联系中的 MGC响应了ServiceChange命令，则控制联系继续存在而不会中断，而且所有的命令都正常处理就如同不存在通信丢失一样。否则，当 MG向新的 MGC发送ServiceChange命令时，最初的控制联系将被终止，而且所有来自先前控制联系的命令都将被忽略。一旦新 MGC响应了 ServiceChange并完成注册过程，则新的控制联系就建立了。
如果MG遍历了 MGC列表而不能够成功地建立控制联系，则 MG等待一段随机长度的时间后又继续向其列表中的MGC尝试注册，从最初控制联系的MGC开始尝试。每次MG尝试与最初控制联系的MGC联系时，MG向该MGC发送ServiceChangeMethod＝"Disconnected"的ServiceChange。MG向所有其他 MGC发送 ServiceChangeMethod＝"Failover"的ServiceChange。
MGC接收到ServiceChangeMethod＝"Disconnected"的ServiceChange后应该审计MG以确定是否由于丢失消息而发送了状态不匹配的情况。
在这些场景中，推荐使用 ServiceChangeReason＝900 ("Service Restored")，尽管某些特殊的场景可能需要不同的ServiceChangeReason代码。
- 3.7 MG能力变化为了通告 MG能力上的变化， MG发送具有适当的 ServiceChangeMethod、ServiceChangeReason＝916 ("Packages Change")或917 ("Capabilities Change")的ServiceChange。MGC应审计MG以确定 MG的新能力。对于处于业务态的 MG且该MG发送了ServiceChangeMethod＝"Restart"的ServiceChange命令，则在能力改变过程中，控制联系应继续而不被中断，而且MG也不应被认为是经历了系统重启。
- 3.8 MGC发起MG重新注册
通过在Root终结点上发出 ServiceChange命令，MGC可以请求MG重新注册，在该 ServiceChange命令中，ServiceChangeMethod＝"Handoff"，ServiceChangeReason＝903 ("MGC Directed Change")，并携带其自身的ServiceChangeMgcID (即当前MGC)。
MG所采取的动作参见3.2。
3.9 MGC发起业务恢复
为了请求MG重新启动，MGC向MG发送ServiceChange命令，其中 ServiceChangeMethod＝"Restart"， ServiceChangeReason为适当的代码，诸如 900("Service Restored")或901("Cold Boot")。按照3.2规定，MG必须使用明确的ServiceChangeReason来建立新的控制联系。
为了恢复某个终结点或某组终结点上的业务， MGC在所涉及的终结点上发送 ServiceChangeMethod="Restart"的ServiceChange命令。 MGC所采取的动作参见4.1.2和4.1.3。
ServiceChangeDelay指示业务恢复即将发生之前的时间长度。细节参见5.3。
- 3.10 MGC发起业务取消
- 3.10.1 Root 终结点
为了将MG置于"OutOfService"状态， MGC在Root终结点上发送 ServiceChangeMethod＝"Forced"或 "Graceful"的ServiceChange命令。适当的 ServiceChangeReasons可以包括 905("Termination taken out of service")。MGC所采取的动作参见4.1.1。
ServiceChangeDelay指示业务取消即将结束之前的时间长度。细节参见5.3。
为了取消先前对整个 MG发出的（和已确认的） Graceful事件，MGC在Root终结点上发送 ServiceChangeMethod＝"Restart"和ServiceChangeReason＝918("Cancel Graceful")的ServiceChange命令。 MG将仍保持在 InService状态，而且先前设置成 OutOfService的所有终结点都返回业务态，除了那些被 MG告知的终结点外。在 Delay定时器超时之后接收到 Cancel Graceful的事件中， MG应向MGC报告差错代码 502("Not Ready")。MG将被要求重新注册以返回业务态。
3.10.2 物理终结点
为了将某个终结点或某组终结点置于 "OutOfService"状态， MGC在这些终结点上发送 ServiceChangeMethod＝"Forced"或"Graceful"的ServiceChange命令。适当的 ServiceChangeReasons可以包括 904 ("Termination malfunctioning")、905 ("Termination taken out of service")、906 ("Loss of lower layer connectivity")或907 ("Transmission failure")。MGC所采取的动作参见4.2和4.3。
ServiceChangeDelay指示业务取消即将结束之前的时间长度。细节参见5.3。
为了取消先前对某个终结点或某组终结点发出的（和已确认的） Graceful事件， MG在这些终结点上发送ServiceChangeMethod＝"Restart"和ServiceChangeReason＝918("Cancel Graceful")的ServiceChange命令。这些终结点将仍保持在 InService状态。在终结点已经转移到 OutOfService状态的事件中，终结点应该返回至业务状态就如同它使用ServiceChange Restart一样。
3.10.3 临时终结点 MGC应不使用ServiceChange来取消临时终结点的业务。从关联中减去终结点就足够删除终结点了。
3.11 MGC故障冗余
当控制联系中的 MGC遭遇到维护或故障情况以至于 MGC必须进入 OutOfService状态，则 MGC可以通过向MG发送ServiceChangeMethod＝"Handoff"、ServiceChangeReason＝903 ("MGC Directed Change")、 ServiceChangeMgcID参数设置为新 MGC地址的 ServiceChange命令来引导 MG向特定的备用 MGC注册。一旦接收到 MG的响应，控制联系将被终止。 MG向指定的 MGC发送ServiceChangeMethod＝"Handoff"、 ServiceChangeReason＝903 ("MGC Directed Change")的ServiceChange命令。一旦接收到来自 MGC的响应，则新的控制联系就建立了。
如果指定MGC拒绝了切换请求或 MGC由于故障不能够发送带有 ServiceChangeMethod Handoff的 ServiceChange命令，则 MG应按照 3.6所述来执行失去通信的程序，并从其先前预置的主控 MGC开始遍历。
- 4 ServiceChange单元描述
- 4.1 ServiceChangeMethod
本小节描述了不同终结点类型上的ServiceChangeMethod行为。本小节组织如下：
- • Root终结点；
- • 物理终结点；
- • 临时终结点。
4.1.1 在Root终结点上的ServiceChange Method行为
依据不同的ServiceChangeMethod，在Root终结点上的 ServiceChange命令有不同的效果。每个 ServiceChangeMethod的结果描述如下：
1) Restart —当由MG发送时，用于通告 MG重新启动了并希望重新协商协议版本、 Profile或通告能力的变化。ServiceChangeReason指示MGC所应该采取的动作。当由 MGC发送该参数时，则 MG应使用所指示的ServiceChangeReason重新启动。
| 2) | Forced —当由MG发送时，MG指示它将立刻进入OutOfService状态。 MG一旦接收到来自MGC的命令响应， MG就终止控制联系。当由 MGC发送时， MG应使其自身置于 OutOfService状态，并在 |
| 发送命令响应之后终止控制联系。注意： MGC不能够使 MG重新返回业务态，尽管 MGC可以请 | |
| 求MG进入OutOfService状态。MG向MGC发起注册以建立新的控制联系并指示业务恢复，就如同 | |
| 它完全其他的注册程序一样。 ServiceChangeDelay对ServiceChangeMethod＝"Forced"没有任何影响。 | |
| 3) | Graceful—当由 MG发送时，指示 MG将在ServiceChangeDelay期间的结束时进入 OutOfService状态。控制联系将在 ServiceChangeDelay期间的结束时被终止。当由 MGC发送时， MG将其自身置于 OutOfService状态并在 ServiceChangeDelay期间的结束时终止控制联系。使用 ServiceChangeDelay＝0或不使用 ServiceChangeDelay指示MG应进入 OutOfService并终止控制联系，当最后一个关联通过删减其终结点而被删除时，并指示 MGC不应增加新连接。 MG应在 |
| ServiceChangeDelay期满后设置Root终结点的ServiceStates属性为“ OutOfService”或从活动的关联中消除所有终结点（不管哪个是第一个）。为了取消先前发送的（和已确认的） ServiceChange命令且该命令的 ServiceChangeMethod＝"Graceful"，发起 ServiceChangeMethod＝Graceful的实体发送 ServiceChangeMethod＝ Restart和 ServiceChangeReason＝ 918 ("Cancel Graceful")的 ServiceChange命令。 | |
| 4) | Failover —当由MG向MGC发送且该MGC不在当前控制联系中时，MG指示其当前MGC已经发生故障了，它正通过接收响应命令来尝试注册。当由 MG向MGC发送且该 MGC在当前控制联系中 |
| 时，主控MG指示备用MG已经切换了出现故障的主控 MG。不管在哪种情况下，一旦发送了 | |
| ServiceChange命令则先前的控制联系被终止，一旦接收到命令响应，则新的控制联系在 MG与新 MGC或 MGC与新的 MG之间建立。 MGC不应发送 ServiceChangeMethod＝ "Failover"的 ServiceChange命令。 | |
| 5) | Handoff —当由MGC发送时， MGC指示MG将转移至新的 MGC。一旦接收到命令响应，这将终止当前的控制联系。当由 MG发送至 MGC时，这指示 MG正在按照在先前控制联系上接收到的 |
| MGC发送的切换命令来尝试建立新的控制联系。当由 MG发送至 MGC时，切换就是一个注册过 | |
| 程，一旦接收到命令响应就建立了新的控制联系。没有 MGC命令MG这样做，MG不应使用 | |
| Handoff。 | |
| 6) | Disconnected—当由 MG发送时，指示当前控制联系的通信已经丢失，但是现在已经重新建立了。当前控制联系被更新了。 MGC不应发送 ServiceChangeMethod＝ "Disconnected"的 |
ServiceChange命令。
4.1.2 在物理终结点上的ServiceChange Method行为
当MG处于活动的控制联系中时，依据不同的 ServiceChangeMethod，在物理终结点上的 ServiceChange命令有不同的效果。每个ServiceChangeMethod的结果描述如下：
1) Restart —当由MG发送时，用于通告终结点已经重新启动了或通告能力的变化。 ServiceChangeReason指示MGC所应该采取的动作。当由 MGC发送该参数时，则 MG应使用所指示的ServiceChangeReason重新启动终结点。
| 2) | Forced —当由MG发送时，指示终结点将立刻进入 OutOfService状态。当由 MGC发送时， MG应使终结点立即置于 OutOfService状态。在以上两种情况下， ServiceStates参数应设置为 |
| "OutOfService"且MGC负责清除与该终结点相关的任何关联或资源。ServiceChangeDelay对 ServiceChangeMethod＝"Forced"没有任何影响。 | |
| 3) | Graceful —当由MG发送时，指示终结点将在 ServiceChangeDelay期间的结束时进入 OutOfService状态。当由 MGC发送时， MG将在ServiceChangeDelay期间的结束时把该终结点置于 OutOfService状态。一旦 ServiceChangeDelay 期满，或当终结点从活动的关联（不管哪个是第一个）中被删除且MGC负责清除与终结点相关的任何关联或资源时， ServiceStates属性就应设置为 |
| "OutOfService"。使用ServiceChangeDelay＝0或不使用 ServiceChangeDelay指示终结点应进入 OutOfService，当通过删减命令将该终结点从关联中删除时。 MGC不应为所指示的终结点建立连 | |
| 接直到Graceful被取消或终结点由后续的 ServiceChange命令重新返回业务。为了取消先前发送的（和已确认的）ServiceChange命令且该命令的 ServiceChangeMethod＝"Graceful"，发起 ServiceChangeMethod＝Graceful的实体发送 ServiceChangeMethod＝Restart和ServiceChangeReason＝918 ("Cancel Graceful")的ServiceChange命令。 | |
| 4) | Failover — ServiceChangeMethod＝"Failover"不应用在非Root终结点上。 |
| 5) | Handoff — ServiceChangeMethod＝"Handoff"不应用在非Root终结点上。 |
| 6) | Disconnected — ServiceChangeMethod＝"Disconnected"不应用在非 Root终结点上。 |
4.1.3 在临时终结点上的ServiceChange Method 行为
当MG处于活动的控制联系中时，依据不同的 ServiceChangeMethod，在临时终结点上的 ServiceChange命令有不同的效果。每个ServiceChangeMethod的结果描述如下：
- 1) Restart —当由MG发送时，用于通告终结点已经重新启动了或通告能力的变化。 ServiceChangeReason指示 MGC所应该采取的动作。 MGC不应向临时终结点发送 ServiceChangeMethod＝"Restart"。
- 2) Forced —当由 MG发送时，指示终结点将立刻进入OutOfService状态。MGC负责删减终结点。 MGC不应向临时终结点发送 ServiceChangeMethod＝ "Forced"。 ServiceChangeDelay对 ServiceChangeMethod＝"Forced"没有任何影响。
- 3) Graceful —当由MG发送时，指示终结点将在 ServiceChangeDelay期间的结束时进入 OutOfService状态。MGC负责在ServiceChangeDelay期满时删减终结点。 MGC不应向临时终结点发送 ServiceChangeMethod＝ "Graceful"。当终结点通过删除命令下关联中删除时，使用 ServiceChangeDelay＝0指示终结点将被消灭。 MG将在ServiceChangeDelay期满或将该终结点从活动关联（不管哪个是第一个）中消除时把该终结点的ServiceStates属性置于 "Out of Service"状态。为了取消先前发送的（和已确认的） ServiceChange命令且该命令的ServiceChangeMethod＝ "Graceful"，发起ServiceChangeMethod＝Graceful的实体发送ServiceChangeMethod＝Restart和 ServiceChangeReason＝918 ("Cancel Graceful")的ServiceChange命令。
- 4) Failover — ServiceChangeMethod＝"Failover"不应用在非Root终结点上。
- 5) Handoff — ServiceChangeMethod＝"Handoff"不应用在非Root终结点上。
- 6) Disconnected — ServiceChangeMethod＝"Disconnected"不应用在非 Root终结点上。
- 5 ServiceChange 参数的使用
- 5.1 ServiceChangeMethod 参见4中所描述的用法。
- 5.2 ServiceChangeReason
ServiceChangeReasons允许接收端改变其行为以适应特殊的环境。例如，如果 MG在其重新启动时向 MGC发送ServiceChangeReason＝901 ("Cold Boot")，则MGC可以假设 MG脱离了其所有的状态，因此， MGC将不执行维护和审计任务以评估和整理MG至可用状态。
表1显示了特定ServiceChangeReasons发送时所携带的ServiceChangeMethod。
表 1/H.248.1 – ServiceChangeMethod和ServiceChangeReason映射 表 1/H.248.1 – ServiceChangeMethod和ServiceChangeReason映射
| SC 原因 | SC方法 | 描述 | |||||
|---|---|---|---|---|---|---|---|
| 重启 | 强制 | 暂缓 | 拆线 | 故障转移 | 切换 | ||
| 900 | X | 仅用于根终结点和MG | 业务恢复 | ||||
| 901 | 仅用于 | 冷启动 | |||||
| 根终结 | |||||||
| 点 | |||||||
| 902 | 仅用于 | 热启动 | |||||
| 根终结 | |||||||
| 点 | |||||||
| 903 | 仅用于 | MGC重定向 | |||||
| 根终结 | |||||||
| 点 | |||||||
| 904 | X | X | 终结点故障 | ||||
| 905 | X | X | 终结点退出服务 | ||||
| 906 | X | X | 底层连接丢失 | ||||
| 907 | X | X | 传输故障 | ||||
| 908 | 仅用于 | 仅用于 | 仅用于 | MG临近故障 | |||
| 根终结 | 根终结 | 根终结 | |||||
| 点和 MG | 点和MG | 点和MG | |||||
| 909 | 仅用于 | MGC临近故障 | |||||
| 根终结 | |||||||
| 点和MG | |||||||
| 910 | 仅用于 MG | X | X | 媒体能力故障 | |||
| 911 | 仅用于 | X | X | Modem能力故障 | |||
| SC 原因 | SC方法 | 描述 | |||||
|---|---|---|---|---|---|---|---|
| 重启 | 强制 | 暂缓 | 拆线 | 故障转移 | 切换 | ||
| MG | |||||||
| 912 | 仅用于 MG | X | X | Mux能力故障 | |||
| 913 | 仅用于 MG | X | X | 信号能力故障 | |||
| 914 | 仅用于 MG | X | X | 事件能力故障 | |||
| 915 | X | X | 状态丢失 | ||||
| 916 | X | 仅用于根终结 | 仅用于 | 包类型改变 | |||
| 点和MG | 根终结 | ||||||
| 点和MG | |||||||
| 917 | X | 仅用于根终结 | 仅用于 | 能力改变 | |||
| 点和MG | 根终结 | ||||||
| 点和MG | |||||||
| 918 | X | 取消暂缓 | |||||
| 919 | 仅用于 | 热故障切换 | |||||
| 根终结 | |||||||
| 点和MG | |||||||
| 920 | 仅用于 | 冷故障切换 | |||||
| 根终结 | |||||||
| 点和MG | |||||||