B-TrunC V2.0 TR 002-2014 基于LTE技术的宽带集群通信(B-TrunC)系统（第一阶段）端到端流程.doc

B-TrunC TR TR 002-2014 V2.0

基于LTE技术的宽带集群通信(B-TrunC)系统（第一阶段）端到端流程
Technical Requirements for General Message Flows between Terminals of LTE based Broadband Trunking Communication(B-TrunC) System (Phase 1)

2016年8月

声明：本文件由宽带集群（B-TrunC）产业联盟制定，未来联盟可继续编制完善。本文件版权完全属于宽带集群（B-TrunC）产业联盟。未经许可，不能复制本文件中的任何部分。版权限制适用于所有媒体的复制方式。.

版本修订记录
版本
主要修订内容
日期
V1.0.0
根据技术组第16次会议讨论，补充了UE发起的关机注销、故障弱化下的TAU、故障弱化下的话权管理
2015/3/20
V1.0.1
补充故障弱化下周期性TAU流程
2015/4/13
V1.0.2
3.6.1节，删除“当基站2收到该消息后，应在适当时间在PDCCH上下发若干次SPS激活命令，通知UE群组资源的起始位置”。
2015/5/6
V1.0.3
3.12.6节，增加步骤13: 集群核心网向被叫UE发送视频源指示。
2015/7/22
V1.1.0
增加全双工单呼媒体协商过程说明
2016/1/20
V1.1.1
1）对3.4.5节组呼建立过程补充场景中，增加呼叫类型不一致的处理。
2）增加话权申请过程的承载建立方式说明
2016/2/16
V1.1.2
1）对3.10.2节故障弱化下的注册步骤描述进行修订
2）3.10.5节故障弱化下周期性TAU过程不需要携带组号，删除。
2016/3/10
V1.1.3
增加3.18节环境监听/监视流程，并进行文字修订。
2016/7/25
V1.1.4
对组播短数据流程中空口发送步骤进行描述修订。
2016/8/18
V2.0
联盟统一版本升级
2016/08/22

前 言
本标准是由宽带集群产业（B-TrunC）联盟制定的《基于LTE技术的宽带集群通信(B-TrunC)系统总体技术要求（第一阶段）》系列标准之一，该系列标准的结构和名称如下：
(1) TR 001-2013 基于LTE技术的宽带集群通信(B-TrunC)系统（第一阶段）总体技术要求
(2) TR 002-2014 基于LTE技术的宽带集群通信(B-TrunC)系统（第一阶段）端到端流程
(3) TR 003-2014 基于LTE技术的宽带集群通信(B-TrunC)系统接口技术要求（第一阶段）空中接口
(4) TM 001-2014 基于LTE技术的宽带集群通信(B-TrunC)系统接口测试方法（第一阶段） 空中接口
(5) TR 004-2014 基于LTE技术的宽带集群通信(B-TrunC)系统接口技术要求（第一阶段）终端到集群核心网接口
(6) TM 002-2014 基于LTE技术的宽带集群通信(B-TrunC)系统接口测试方法（第一阶段）终端到集群核心网接口
(7) TR 005-2014 基于LTE技术的宽带集群通信(B-TrunC)系统接口技术要求（第一阶段）集群核心网到调度台接口
(8) TM 003-2014 基于LTE技术的宽带集群通信(B-TrunC)系统接口测试方法（第一阶段）集群核心网到调度台接口
(9) TR 006-2014 基于LTE技术的宽带集群通信(B-TrunC)系统（第一阶段）网络设备技术要求
(10) TM 004-2014 基于LTE技术的宽带集群通信(B-TrunC)系统（第一阶段）网络设备测试方法
(11) TR 007-2014 基于LTE技术的宽带集群通信(B-TrunC)系统（第一阶段）终端设备技术要求
(12) TM 005-2014 基于LTE技术的宽带集群通信(B-TrunC)系统（第一阶段）终端设备测试方法
(13) TM 006-2014 基于LTE技术的宽带集群通信(B-TrunC)系统（第一阶段）终端与网络互操作测试方法
(14) TR 008-2014 基于LTE技术的宽带集群通信(B-TrunC)系统（第一阶段）调度台设备技术要求
(15) TM 007-2014 基于LTE技术的宽带集群通信(B-TrunC)系统（第一阶段）调度台设备测试方法
(16) TM 008-2015 基于LTE技术的宽带集群通信(B-TrunC)系统（第一阶段）产品认证测试集
(17) TM 009-2015 基于LTE技术的宽带集群通信(B-TrunC)系统（第一阶段）调度台与系统IOT测试方法
(18) TM 010-2016 基于LTE技术的宽带集群通信(B-TrunC)系统（第一阶段）终端设备射频测试方法
(19) TM 011-2016 基于LTE技术的宽带集群通信(B-TrunC)系统（第一阶段）基站设备射频测试方法
(20) SC 001-2015 基于LTE技术的宽带集群通信(B-TrunC)系统（第一阶段）标准澄清文件

随着技术的发展，还将制定后续的相关标准。
本标准按照GB/T 1.1-2009给出的规则起草。本标准由宽带集群（B-TrunC）产业联盟提出并归口。

本标准起草单位：北京中兴高达通信技术有限公司、中国信息通信研究院、普天信息技术有限公司、鼎桥通信技术有限公司、北京信威通信技术股份有限公司、中兴通讯股份有限公司、华为技术有限公司、大唐电信科技产业集团、海能达通信股份有限公司
本标准主要起草人：毛磊、蔡杰、陈迎、郑伟、龚达宁、王璐、杨美荟、周志宏、赵洪坤、徐霞艳、宋得龙、褚丽、李晓华、周波、唐春莺、贾瑞凯、康艳超、徐晖、杨小倩、丁俊、黄志强、潘磊、王小平、王芳、王彬、张成文

目 次
版本修订记录 I
前 言 II
基于LTE技术的宽带集群通信(B-TrunC)系统架构和端到端流程 5
1 范围 5
2 协议栈架构 5
2.1 控制面协议栈 5
2.2 用户面协议栈 5
3 端到端流程 6
3.1 注册和注销过程 6
3.2 承载管理 12
3.3 语音单呼/可视单呼 14
3.4 语音组呼、可视组呼 25
3.5 话权申请 33
3.6 移动性 41
3.7 迟后进入 43
3.8 点到点实时短数据 44
3.9 组播短数据 45
3.10 故障弱化 47
3.11 遥毙/遥晕/复活 59
3.12 视频调度业务 60
3.13 不同源视频组呼 69
3.14 强插强拆 98
3.15 动态重组和组管理 100
3.16 信息获得 101
3.17 端到端加密 102
4 其他功能实现（不涉及单独流程） 116
4.1 紧急呼叫 116
4.2 缩位拨号 117
4.3 通话限时 117
4.4 授权呼叫 117
4.5 调度区域选择 117

基于LTE技术的宽带集群通信(B-TrunC)系统架构和端到端流程
1　 范围
本标准规定了基于LTE技术的宽带集群通信(B-TrunC)系统架构和端到端流程，包括协议栈架构、端到端流程、其他功能实现等。
本标准适用于基于LTE技术的宽带集群通信(B-TrunC)系统（第一阶段）的终端、基站、集群核心网和调度台设备。
2　 协议栈架构
2.1　 控制面协议栈

图1控制面协议栈
2.2　 用户面协议栈

图2 统一的用户面协议栈

图3可选的语音业务用户面协议栈
3　 端到端流程
3.1　 注册和注销过程
3.1.1　 概述
LTE标准的附着和去附着过程参见行标YD/T 2620.1-2013。本文档仅描述集群相关的流程。
3.1.2　 终端发起的集群注册流程（成功）

图4终端发起的集群注册过程（成功）

流程说明如下：
1） 步骤1：终端先进行完EPS附着过程。
2） 步骤2、3：UE向集群核心网发送TRUNKING REGISTER REQUEST消息，消息中携带Trunking Register Type 、UE Trunking Capability、Stun Status、Audio Codec Capability和Video Codec Capability等信息；UE在故障弱化模式下执行集群注册时，还需携带Subscriber BCD Number，可选携带Group ID List。
3） 步骤4、5：网络侧收到UE的TRUNKING REGISTER REQUEST消息后查找终端的集群签约信息，如果网络侧处理正常向UE回复TRUNKING REGISTER ACCEPT消息，消息内容包括：如果网络要求UE进行周期性注册，则应携带Trunking update period；对UE初始注册过程，网络应携带Subscriber BCD Number；对UE初始注册过程，如果网络配置了用户的别称时，应携带User name；如果网络配置了用户的紧急呼叫号码时，在UE初始注册过程，以及紧急呼叫号码改变等情况下，应携带Emergency num；在初始注册时，以及网络集群能力改变后，应携带Network trunking capability。
4） 步骤6、7：UE接收到TRUNKING REGISTER ACCEPT消息，向网络侧回复TRUNKING REGISTER COMPLETE消息，通知集群注册完成，消息中无内容。
3.1.3　 终端发起的集群注册流程（拒绝）

图5 终端发起的集群注册过程（拒绝）
流程说明如下：
1） 步骤1：终端先进行完EPS注册过程。
2） 步骤2、3：UE向集群核心网发送TRUNKING REGISTER REQUEST消息，消息中携带Trunking Register Type 、UE Trunking Capability、Stun Status、Audio Codec Capability和Video Codec Capability等信息；UE在故障弱化模式下执行集群注册时，还需携带Subscriber BCD Number，可选携带Group ID List。
3） 步骤4、5：网络侧收到UE的TRUNKING REGISTER REQUEST消息后查找终端的集群签约信息，如果出现失败，则网络侧回复TRUNKING REGISTER REJECT消息，其中携带典型拒绝原因值。

3.1.4　 终端发起的集群注销流程

图6终端发起的集群注销过程
流程说明如下：
1） 步骤1：如果UE处于IDLE态，则执行随机接入过程，建立RRC连接和EPS连接。处于RRC连接态的UE不需要执行此步骤。
2） 步骤2：通过上行直传消息发送NAS消息TRUNKING DEREGISTER REQUEST，其中携带有注销原因值(标准注销）。
3） 步骤3：基站通过上行直传消息将该NAS消息透传给集群核心网。
4） 步骤4～5：集群核心网接受终端的集群注销申请，通过步骤4、5发送TRUNKING DEREGISTER ACCEPT给UE。
3.1.5　 终端发起的关机注销流程

图7 终端发起的关机注销流程
流程说明如下：
1） 步骤1：如果UE处于IDLE态，则执行随机接入过程，建立RRC连接和EPS连接。处于RRC连接态的UE不需要执行此步骤。
2） 步骤2：通过上行直传消息发送NAS消息TRUNKING DEREGISTER REQUEST，其中携带有注销原因值(关机注销)。
3） 步骤3：基站通过上行直传消息将该NAS消息透传给集群核心网。
4） 步骤4～5：可选地，集群核心网通过步骤4、5发送TRUNKING DEREGISTER ACCEPT给UE；
3.1.6　 终端发起的关机注销流程（Detach）

图8 终端发起的关机注销流程（detach）
流程说明如下：
1） 步骤1：如果UE处于IDLE态，则执行随机接入过程，建立RRC连接和EPS连接。处于RRC连接态的UE不需要执行此步骤。
2） 步骤2：UE通过上行直传消息发送NAS消息DETACH REQUEST，并删除集群上下文。
3） 步骤3：基站通过上行直传消息将该NAS消息透传给集群核心网。集群核心网接受终端DETACH并删除集群上下文。
3.1.7　 网络发起的集群注销流程

图9网络发起的集群注销流程
流程说明如下：
1） 步骤1：核心网发起集群注销过程。如果UE处于IDLE态，核心网需要先寻呼该终端，终端响应寻呼并建立连接。
2） 步骤2：核心网通过下行直传消息发送NAS消息TRUNKING DEREGISTER REQUEST，消息中携带注销原因值(标准注销：网络侧去激活集群功能/注销后需重新发起注册：网络侧发生不可修复的错误时需要终端重新注册/用户签约数据被删除引起的注销：网络侧删除该用户签约数据)。
3） 步骤3：eNB将TRUNKING DEREGISTER REQUEST传给终端。
4） 步骤4～5：终端接受网络的集群注销命令，通过步骤4、5发送TRUNKING DEREGISTER ACCEPT给集群核心网。
3.1.8　 调度台注册流程

图10调度台注册流程
流程说明：
1） 调度台向集群核心网发送SIP（REGISTER）消息发起注册过程，消息中携带集群业务标识pttregister，并携带Expires：3600头域，可选携带数据查询指示dataquery字段，该字段指示本次数据请求的类型为“全局查询”或者“增量查询”。
2） 集群核心网向调度台发送SIP（401 Unauthorized）消息，要求进行鉴权，携带WWW-Authenticate头域，以标准SIP摘要的形式发起认证挑战。
3） 调度台再次发送SIP（REGISTER）消息到集群核心网，向集群核心网申请业务注册，携带Authorization 头域。
4） 集群核心网向调度台发送SIP（200 OK）消息，注册成功，携带pttregister标识，并可根据步骤1）中SIP（REGISTER）消息的dataquery字段，携带调度台的组信息。

3.1.9　 调度台注销流程

图11调度台注销流程
流程说明：
1） 调度台发送SIP（REGISTER）消息到集群核心网，向集群核心网发起业务注销(Expires:0)，携带集群业务标识pttregister。
2） 集群核心网向调度台发送SIP（401 Unauthorized）消息，要求进行鉴权，携带WWW-Authenticate头域，以标准SIP摘要的形式发起认证挑战。
3） 调度台再次发送SIP（REGISTER）消息到集群核心网，向集群核心网发起业务注销，携带Authorization 头域。
4） 集群核心网向调度台发送SIP（200OK）消息，注销成功，携带pttregister标识。

3.2　 承载管理
3.2.1　 专有承载激活

图12 专有承载激活过程
流程说明如下：
1） 集群核心网向eNodeB发送专用承载建立请求E-RAB Setup Request消息（包括EPS承载ID、EPS承载QoS以及S1-U的TEID），消息中携带一个或多个NAS消息Activate Dedicated EPS Bearer Context Request。
2） eNodeB将EPS承载QoS映射到无线承载QoS，然后向UE发送RRC Connection Reconfiguration 消息。
3） UE向eNodeB发送RRC Connection Reconfiguration Complete消息，确认无线承载激活。
4） eNodeB向EPC发送E-RAB Setup Response消息来确认承载激活。
5） 针对激活的每一个承载，UE的NAS层建立一个Activate Dedicated EPS Bearer Context Accept消息，该消息包括EPS 承载ID，并用UL Information Transfer消息发送至eNodeB。
6） eNodeB收到步骤5的消息后，向集群核心网发送Uplink NAS Transport消息，消息携带Activate Dedicated EPS Bearer Context Accept消息。

对于激活的每一个承载，步骤5、6均应执行一次。
3.2.2　 核心网发起的专有承载去激活

图13 核心网发起的专有承载去激活
流程说明如下：
1） 集群核心网通过S1AP向eNodeB发送专用承载去激活请求E-RAB Release Command消息，消息中同时携带NAS消息Deactivate EPS Bearer Context Request，该消息包括了去激活的原因以及PTI等参数。
2） eNodeB向UE发送RRC Connection Reconfiguration 消息，内容包括要删除的EPS Radio Bearer Identity。消息中同时携带NAS消息Deactivate EPS Bearer Context Request。
3） UE发送RRC Connection Reconfiguration Complete消息给eNodeB作为响应。
4） eNodeB向集群核心网发送E-RAB Release Response(EPS Bearer Identity)消息来确认承载去激活。
5） UE的 NAS层建立一个Deactivate EPS Bearer Context Accept消息，该消息包括EPS 承载ID。然后UE向eNodeB发送UL Information Transfer消息，消息携带该NAS消息。
6） eNodeB向集群核心网发送Uplink NAS Transport消息，消息携带Deactivate EPS Bearer Context Accept消息。

3.3　 语音单呼/可视单呼
3.3.1　 单呼建立流程
3.3.1.1　 终端发起的单呼建立

图14终端发起的单呼建立流程
流程说明如下：
1） 步骤1a: 如是处于ECM-IDLE态的UE，需要先通过SERVICE REQUEST流程，和网络恢复连接。
2） 步骤1：主叫UE通过NAS消息CALL REQUEST，通知网络需要建立全双工单呼, 携带媒体格式,主要包括：Call Type，Call Attribute，Called Number，Audio Description（如果Call Type业务中包含音频媒体），Video Description（如果Call Type业务中包含视频媒体）。
3） 步骤2：如被叫为和网络没有连接的UE，则核心网通过Trunking Paging通知UE，相关的呼叫到达。
4） 步骤3：被叫UE通过SERVICE REQUEST流程，和网络配合，恢复空口承载以及信令连接。
5） 步骤4：核心网通过CALL REQUEST消息，通知被叫UE此次呼叫的相关信息,携带媒体格式，主要包括：Call ID，Caller Number，Call Type，Call Attribute，Call Priority，Audio Description（如果Call Type业务中包含音频媒体），Video Description（如果Call Type业务中包含视频媒体）。
6） 步骤5：被叫UE通过CALL CONFIRMED消息，通知核心网本UE已收到CALL REQUEST. 携带媒体格式，主要包括：Call ID，Audio Description（如果Call Type业务中包含音频媒体），Video Description（如果Call Type业务中包含视频媒体）。
7） 步骤6：网络通过CALL PROCEEDING，通知主叫媒体格式，主要包括：Call ID， Call Type，Call Attribute，Priority，Audio Description（如果Call Type业务中包含音频媒体），Video Description（如果Call Type业务中包含视频媒体）。如果网络决策，call proceeding与被叫侧call request、call confirm无时序关系；如果协商决定，则有时序关系。
8） 步骤7：网络和被叫UE配合，建立相应的专用承载。
9） 步骤8：网络和主叫UE配合，建立相应的专用承载。
10） 步骤9~10：被叫振铃，通过网络，通知主叫UE。
11） 步骤11：被叫摘机后，通过CALL CONNECT通知核心网。
12） 步骤12：核心网通过CALL CONNECT通知主叫UE，被叫已摘机，可以进行数据传输。
13） 步骤13：主叫UE反馈CALL CONNECT ACK给核心网，相应CALL CONNECT已收到。
14） 步骤14：核心网向被叫UE反馈主叫UE已收到CALLCONNECT。
15） 主叫和被叫开始通话。

在上述单呼建立过程中，媒体协商过程规定如下：
l 对于一次单呼，编码和解码应该使用相同的参数。
l 单呼媒体协商可以由网络决定或被叫决定。
l 主叫提供本次呼叫建议的1套或多套媒体参数作为候选
² 如果是网络决定，则网络在主叫提供的候选参数中，根据被叫能力取交集，并在交集中选择1套参数发给被叫；如果没有交集，则网络使用标准规定的默认支持媒体配置，发送给被叫。
² 如果是被叫决定，则网络应将主叫提供的候选媒体参数发给被叫。
l 被叫根据自己的能力，与收到的媒体参数取交集，并在交集中选择1套参数发给网络；如果没有交集，则被叫使用标准规定的默认支持媒体配置，发送给网络。
进一步，对于彩铃的配置，规定如下：
（1）网络不使用彩铃的情况下：网络发给主叫的alerting消息中不携带媒体参数。被叫发给网络的call connnect消息，可选携带媒体参数，如果携带，则媒体参数应与call confirmed消息中的媒体参数一致。网络发给主叫的call connnect消息中可选携带媒体参数，如果携带，则媒体参数应与call proceeding消息中的媒体参数一致。
（2）网络使用彩铃情况下，应在alerting消息中携带彩铃的媒体参数。被叫发给网络的call connnect消息，可选携带媒体参数，如果携带，则媒体参数应与call confirmed消息中的媒体参数一致。网络发给主叫的call connect消息中应携带媒体参数，且媒体参数应与call proceeding消息中的媒体参数一致。

3.3.1.2　 终端发起的半双工单呼建立—无应答方式（可选）

图15终端发起的半双工单呼建立流程

流程说明如下：
1） 步骤1～5：发起者UE执行RRC连接建立流程。UE在连接建立完成消息中携带NAS消息，TRUNKING SERVICE REQUEST，其中除了安全信息外，携带呼叫请求CALL REQUEST，用以申请建立一个半双工单呼业务。CALL REQUEST携带媒体格式,主要包括：Call Type，Call Attribute，Called Number，Audio Description（如果Call Type业务中包含音频媒体），Video Description（如果Call Type业务中包含视频媒体）。
2） 步骤6：基站通过INITIAL UE MESSAGE向核心网发送初始UE消息，携带TRUNKING SERVICE REQUEST。
3） 步骤7：核心网和UE之间，通过安全鉴权流程来确定用户的合法性。
4） 步骤8：如被叫为和网络没有连接的UE，则核心网通过Trunking Paging通知UE，相关的呼叫到达。
5） 步骤9： 被叫UE通过SERVICE REQUEST流程，和网络配合，恢复空口承载以及信令连接。
6） 步骤10：核心网通过CALL REQUEST消息，通知被叫UE此次呼叫的相关信息。CALL REQUEST消息携带媒体格式，主要包括：Call ID，Caller Number，Call Type，Call Attribute，Call Priority，Audio Description（如果Call Type业务中包含音频媒体），Video Description（如果Call Type业务中包含视频媒体）。
7） 步骤11：被叫UE通过CALL CONFIRMED消息，通知核心网本UE已收到CALL REQUEST。CALL CONFIRMED消息携带媒体格式，主要包括：Call ID，Audio Description（如果Call Type业务中包含音频媒体），Video Description（如果Call Type业务中包含视频媒体）。
8） 步骤12：网络和UE配合，建立相应的专用承载。
9） 步骤13：核心网发起触发INITIAL CONTEXT SETUP REQUEST给基站，其中，携带有核心网给UE建立的专用承载(Qos, TFT)信息，供发起者上行传输使用主被叫时序没有关系。
10） 如果消息13中配置了UE Radio Capability IE，则基站不会发送消息14 UECapabilityEnquiry消息给UE，即没有第14-16步过程；否则会触发流程14~16，UE上报无线能力信息后，基站通过UE CAPABILITY INFO INDICATION上报UE的无线能力信息。
11） 步骤17～18：eNB执行空口安全模式操作，激活对应空口的安全机制。
12） 步骤19:eNB通过RRC重配，恢复UE的空口承载，同时，携带专用承载建立请求，建立为半双工单呼使用的专用承载。
13） 步骤20~21：UE反馈RRC层的配置结果给基站。基站通过INITIAL CONTEXT SETUP RESPONSE反馈结果给核心网。
14） 步骤22：UE通过上行直传，向核心网反馈NAS层专用承载建立的结果。
15） 步骤23~24：核心网通过CALL ACCEPT通知发起者，相应资源已准备完毕，可以进行上行传输。UE通过CALL COMPLETE通知核心网，CALL ACCEPT已被UE获得。CALL ACCEPT消息携带媒体格式，主要包括：Call ID，Call Type，Call Attribute，Priority，Floor Status，Audio Description（如果Call Type业务中包含音频媒体），Video Description（如果Call Type业务中包含视频媒体）。
16） 主叫UE获得话权，开始数据传输。
17） 步骤25：核心网通过FLOOR INFORM流程，向被叫UE通知当前的话权状态。

3.3.1.3　 调度台发起的单呼建立

图16调度台发起的单呼建立流程
流程说明如下：
1） 步骤1：调度台发送SIP（INVITE）消息，发起单呼建立。
2） 步骤2：核心网向调度台发送SIP（100 TRYING）消息响应。
3） 步骤3－4：寻呼被叫终端，被叫终端建立RRC连接，仅用于被叫终端处于空闲态时。对于连接态被叫终端不需要。
4） 步骤5：网络向被叫终端发起单呼建立CALL REQUEST消息。CALL REQUEST消息携带媒体格式，主要包括：Call ID，Caller Number，Call Type，Call Attribute，Call Priority，Audio Description（如果Call Type业务中包含音频媒体），Video Description（如果Call Type业务中包含视频媒体）。
5） 步骤6：被叫终端发送Call Confirmed消息响应，携带被叫媒体信息，主要包括：Call ID，Audio Description（如果Call Type业务中包含音频媒体），Video Description（如果Call Type业务中包含视频媒体）。
6） 步骤7：被叫终端建立专用承载。
7） 步骤8：被叫终端发送Alerting消息。
8） 步骤9：核心网向调度台发送SIP（180 RINGING）消息振铃，可选携带给主叫的媒体信息。
9） 步骤10：被叫终端发送CALL Connect消息。
10） 步骤11：核心网向调度台发送SIP（200 OK）消息，如果180 RINGING没有携带给主叫的媒体信息，在200 OK携带给主叫的媒体信息。如果网络决策，主被叫无时序关系；如果协商决定，则有如图所示的时序关系。
11） 步骤12：网络向被叫终端发CALL Connect ACK消息响应。
12） 步骤13：调度台向核心网发送SIP（ACK）消息。

3.3.1.4　 调度台发起的半双工单呼建立—无应答方式（可选）

图17调度台发起的半双工单呼建立
流程说明如下：
1） 步骤1：调度台发送SIP（INVITE）消息，发起单呼建立。
2） 步骤2：核心网回复100 Trying。
3） 步骤3：核心网寻呼被叫。
4） 步骤4：终端响应寻呼，建立RRC连接。
5） 步骤5：网络向被叫终端发起单呼建立CALL REQUEST消息。主被叫时序没有关系。CALL REQUEST消息携带媒体格式，主要包括：Call ID，Caller Number，Call Type，Call Attribute，Call Priority，Audio Description（如果Call Type业务中包含音频媒体），Video Description（如果Call Type业务中包含视频媒体）。
6） 步骤6：被叫终端发送Call Confirmed消息响应。Call Confirmed消息携带媒体格式，主要包括：Call ID，Audio Description（如果Call Type业务中包含音频媒体），Video Description（如果Call Type业务中包含视频媒体）。
7） 步骤7：被叫终端建立专用承载。
8） 步骤8：核心网向调度台发送SIP（200 OK）消息。
9） 步骤9：被叫终端发送FLOOR INFORM消息。
10） 步骤10：调度台向核心网发送SIP（ACK）消息。

3.3.1.5　 终端发起单呼呼叫调度台

图18终端发起单呼呼叫调度台
流程说明如下：
1） 步骤1a: 如是处于ECM-IDLE态的UE，需要先通过SERVICE REQUEST流程，和网络恢复连接。
2） 步骤1：主叫UE通过NAS消息CALL REQUEST，通知网络需要建立全双工单呼。携带媒体格式,主要包括：Call Type，Call Attribute，Called Number，Audio Description（如果Call Type业务中包含音频媒体），Video Description（如果Call Type业务中包含视频媒体）。
3） 步骤2：核心网发送INVITE消息，通知调度台此次呼叫的相关信息。
4） 步骤3：调度台发送100 TRYING消息。
5） 步骤4：调度台摘机，发送180 RINGING消息。
6） 步骤5：网络侧确定UE的媒体信息，通过CALL PROCEEDING，通知主叫UE此次呼叫的协商结果，主要包括：Call ID， Call Type，Call Attribute，Priority，Audio Description（如果Call Type业务中包含音频媒体），Video Description（如果Call Type业务中包含视频媒体）。
7） 步骤6：如果网络决策媒体信息，网络和主叫UE配合，建立相应的专用承载（6a）。如果端到端协商决定，则核心网收到调度台发送SIP（200 OK）消息中携带的媒体信息后，建立相应的专用承载（6b）。
8） 步骤7：核心网向终端发送PTP Alerting消息振铃。
9） 步骤8：调度台发送SIP（200 OK）消息，携带媒体信息。如果网络决策，主被叫无时序关系；如果协商决定，则有如图所示的时序关系。
10） 步骤9：核心网通过CALL CONNECT通知主叫UE，被叫已摘机，可以进行数据传输。
11） 步骤10：核心网发送SIP（ACK）消息。
12） 步骤11：主叫UE反馈CALL CONNECT ACK给核心网，相应CALL CONNECT已收到。
13） 主叫和被叫开始通话。

3.3.2　 单呼释放流程
3.3.2.1　 终端发起的单呼释放

图19终端发起的单呼释放流程
流程说明如下：
1） 步骤1：正在通话的UE1按下挂断键发起呼叫释放过程，UE1发送CALL RELEASE REQUEST消息给eCN。
2） 步骤2：核心网向UE2发送CALL RELEASE REQUEST消息。
3） 步骤3： UE2向核心网发送CALL RELEASE RESPONSE消息。
4） 步骤4：核心网向UE1发送CALL RELEASE RESPONSE消息。
5） 步骤5：UE1执行专用承载释放过程。
3.3.2.2　 调度台发起的单呼释放

图20调度台发起的单呼释放
流程说明如下：
1） 步骤1：调度台发送SIP（bye）消息，发起单呼释放。
2） 步骤2：核心网向UE发送CALL RELEASE REQUEST消息。
3） 步骤3： UE向核心网发送CALL RELEASE RESPONSE消息。
4） 步骤4：核心网向调度台发送SIP（200 ok）消息。
5） 步骤5：UE执行专用承载释放过程。步骤4和步骤5可以并行，没有时序关系。

3.4　 语音组呼、可视组呼
3.4.1　 用户发起的组呼建立流程

图21用户发起的组呼建立流程

说明：上述流程图为IDLE态UE触发的组呼建立过程。如果组呼发起者为连接态UE，则通过NAS直传消息携带CALL REQUEST。。
流程说明如下：

1） 步骤1～5：发起组呼的IDLE UE执行RRC连接建立流程。UE在连接建立完成消息中携带NAS消息TRUNKING SERVICE REQUEST，其中除了安全信息外，携带呼叫请求CALL REQUEST（消息中携带呼叫类型、呼叫属性、被叫号码、媒体信息等），用以申请建立一个集群组呼业务。
2） 步骤6：基站通过INITIAL UE MESSAGE向核心网发送初始UE消息，携带TRUNKING SERVICE REQUEST。
3） 步骤7：核心网和UE之间，通过安全鉴权流程来确定用户的合法性。
4） 步骤8：核心网发起触发INITIAL CONTEXT SETUP REQUEST给基站，其中，携带有核心网给UE建立的专用承载(Qos, TFT)，供发起者上行传输使用。
5） 如果消息8中配置了UE Radio Capability IE，则基站不会发送消息9 UECapabilityEnquiry消息给UE，即没有第9-11步过程；否则会触发流程9～11，UE上报无线能力信息后，基站通过UE CAPABILITY INFO INDICATION上报UE的无线能力信息。
6） 步骤12～13：eNB执行空口安全模式操作，激活对应