TR002-2014B-TrunC端到端流程_第1頁
TR002-2014B-TrunC端到端流程_第2頁
TR002-2014B-TrunC端到端流程_第3頁
TR002-2014B-TrunC端到端流程_第4頁
TR002-2014B-TrunC端到端流程_第5頁
已閱讀5頁,還剩120頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、寬帶集群(B-TrunC)產業(yè)聯(lián)盟 B-TrunC TR 002-2014 V1.00B-TrunC TR TR 002-2014 V1.00023基于LTE技術的寬帶集群通信(B-TrunC)系統(tǒng)(第一階段)端到端流程Technical Requirements for General Message Flows between Terminals of LTE based Broadband Trunking Communication(B-TrunC) System (Phase 1)2015年3月聲明:本文件由寬帶集群(B-TrunC)產業(yè)聯(lián)盟制定,未來聯(lián)盟可繼續(xù)編制完善。本文件版權完

2、全屬于寬帶集群(B-TrunC)產業(yè)聯(lián)盟。未經許可,不能復制本文件中的任何部分。版權限制適用于所有媒體的復制方式。.109版本修訂記錄版本主要修訂內容日期V1.00根據技術組第16次會議討論,補充了UE發(fā)起的關機注銷、故障弱化下的TAU、故障弱化下的話權管理2015/3/20V1.01補充故障弱化下周期性TAU流程2015/4/13V1.023.6.1節(jié),刪除“當基站2收到該消息后,應在適當時間在PDCCH上下發(fā)若干次SPS激活命令,通知UE群組資源的起始位置”。2015/5/6V1.033.12.6節(jié),增加步驟13: 集群核心網向被叫UE發(fā)送視頻源指示。2015/7/22前 言本標準是由寬帶

3、集群產業(yè)(B-TrunC)聯(lián)盟制定的基于LTE技術的寬帶集群通信(B-TrunC)系統(tǒng)總體技術要求(第一階段)系列標準之一,該系列標準的結構和名稱預計如下:(1) TR 001-2013 基于LTE技術的寬帶集群通信(B-TrunC)系統(tǒng)(第一階段)總體技術要求(2) TR 002-2014 基于LTE技術的寬帶集群通信(B-TrunC)系統(tǒng)(第一階段)端到端流程 (3) TR 003-2014 基于LTE技術的寬帶集群通信(B-TrunC)系統(tǒng)接口技術要求(第一階段)空中接口 (4) TM 001-2014 基于LTE技術的寬帶集群通信(B-TrunC)系統(tǒng)接口測試方法(第一階段) 空中接口

4、 (5) TR 004-2014 基于LTE技術的寬帶集群通信(B-TrunC)系統(tǒng)接口技術要求(第一階段)終端到集群核心網接口(6) TM 002-2014 基于LTE技術的寬帶集群通信(B-TrunC)系統(tǒng)接口測試方法(第一階段)終端到集群核心網接口 (7) TR 005-2014 基于LTE技術的寬帶集群通信(B-TrunC)系統(tǒng)接口技術要求(第一階段)集群核心網到調度臺接口 (8) TM 003-2014 基于LTE技術的寬帶集群通信(B-TrunC)系統(tǒng)接口測試方法(第一階段)集群核心網到調度臺接口 (9) TR 006-2014 基于LTE技術的寬帶集群通信(B-TrunC)系統(tǒng)(

5、第一階段)網絡設備技術要求(10) TM 004-2014 基于LTE技術的寬帶集群通信(B-TrunC)系統(tǒng)(第一階段)網絡設備測試方法(11) TR 007-2014 基于LTE技術的寬帶集群通信(B-TrunC)系統(tǒng)(第一階段)終端設備技術要求(12) TM 005-2014 基于LTE技術的寬帶集群通信(B-TrunC)系統(tǒng)(第一階段)終端設備測試方法(13) TM 006-2014 基于LTE技術的寬帶集群通信(B-TrunC)系統(tǒng)(第一階段)終端與網絡互操作測試方法 (14) TR 008-2014 基于LTE技術的寬帶集群通信(B-TrunC)系統(tǒng)(第一階段)調度臺設備技術要求

6、(15) TM 007-2014 基于LTE技術的寬帶集群通信(B-TrunC)系統(tǒng)(第一階段)調度臺設備測試方法 (16) SC 001-2015 基于LTE技術的寬帶集群通信(B-TrunC)系統(tǒng)(第一階段)標準澄清文件隨著技術的發(fā)展,還將制定后續(xù)的相關標準。本標準按照GB/T 1.1-2009給出的規(guī)則起草。本標準由寬帶集群(B-TrunC)產業(yè)聯(lián)盟提出并歸口。本標準起草單位:深圳市中興高達技術有限公司、中國信息通信研究院、普天信息技術有限公司、鼎橋通信技術有限公司、北京信威通信技術股份有限公司、中興通訊股份有限公司、華為技術有限公司、大唐電信科技產業(yè)集團、海能達通信股份有限公司本標準主

7、要起草人:毛磊、蔡杰、陳迎、鄭偉、龔達寧、王璐、楊美薈、周志宏、趙洪坤、徐霞艷、宋得龍、褚麗、李曉華、周波、唐春鶯、賈瑞凱、康艷超、徐暉、楊小倩、丁俊、黃志強、潘磊、王小平、王芳、王彬、張成文目 次版本修訂記錄I前 言II基于LTE技術的寬帶集群通信(B-TrunC)系統(tǒng)架構和端到端流程41 范圍42 協(xié)議棧架構42.1 控制面協(xié)議棧42.2 用戶面協(xié)議棧43 端到端流程53.1 注冊和注銷過程53.2 承載管理113.3 語音單呼/可視單呼133.4 語音組呼、可視組呼233.5 話權申請313.6 移動性403.7 遲后進入433.8 點到點實時短數據433.9 組播短數據453.10 故

8、障弱化473.11 遙斃/遙暈/復活583.12 視頻調度業(yè)務593.13 不同源視頻組呼693.14 強插強拆1013.15 動態(tài)重組和組管理1043.16 信息獲得1043.17 端到端加密1064 其他功能實現(不涉及單獨流程)1224.1 緊急呼叫1234.2 縮位撥號1234.3 通話限時1234.4 授權呼叫1234.5 調度區(qū)域選擇123基于LTE技術的寬帶集群通信(B-TrunC)系統(tǒng)架構和端到端流程1 范圍本標準規(guī)定了基于LTE技術的寬帶集群通信(B-TrunC)系統(tǒng)架構和端到端流程,包括協(xié)議棧架構、端到端流程、其他功能實現等。本標準適用于基于LTE技術的寬帶集群通信(B-T

9、runC)系統(tǒng)(第一階段)的終端、基站、集群核心網和調度臺設備。2 協(xié)議棧架構2.1 控制面協(xié)議棧圖1控制面協(xié)議棧2.2 用戶面協(xié)議棧圖2 統(tǒng)一的用戶面協(xié)議棧圖3可選的語音業(yè)務用戶面協(xié)議棧3 端到端流程3.1 注冊和注銷過程3.1.1 概述LTE標準的附著和去附著過程參見行標YD/T 2620.1-2013。本文檔僅描述集群相關的流程。3.1.2 終端發(fā)起的集群注冊流程(成功)圖4終端發(fā)起的集群注冊過程(成功)流程說明如下:1) 步驟1:終端先進行完EPS附著過程。2) 步驟2、3:UE向集群核心網發(fā)送TRUNKING REGISTER REQUEST消息,消息中攜帶Trunking Regi

10、ster Type 、UE Trunking Capability、Stun Status、Audio Codec Capability和Video Codec Capability等信息;UE在故障弱化模式下執(zhí)行集群注冊時,還需攜帶Subscriber BCD Number,可選攜帶Group ID List。3) 步驟4、5:網絡側收到UE的TRUNKING REGISTER REQUEST消息后查找終端的集群簽約信息,如果網絡側處理正常向UE回復TRUNKING REGISTER ACCEPT消息,消息內容包括:如果網絡要求UE進行周期性注冊,則應攜帶Trunking update pe

11、riod;對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 終端發(fā)起的集群注冊流程(拒

12、絕)圖5 終端發(fā)起的集群注冊過程(拒絕)流程說明如下:1) 步驟1:終端先進行完EPS注冊過程。2) 步驟2、3:UE向集群核心網發(fā)送TRUNKING REGISTER REQUEST消息,消息中攜帶Trunking Register Type 、UE Trunking Capability、Stun Status、Audio Codec Capability和Video Codec Capability等信息;UE在故障弱化模式下執(zhí)行集群注冊時,還需攜帶Subscriber BCD Number,可選攜帶Group ID List。3) 步驟4、5:網絡側收到UE的TRUNKING REGI

13、STER REQUEST消息后查找終端的集群簽約信息,如果出現失敗,則網絡側回復TRUNKING REGISTER REJECT消息,其中攜帶典型拒絕原因值。3.1.4 終端發(fā)起的集群注銷流程圖6終端發(fā)起的集群注銷過程流程說明如下:1) 步驟1:如果UE處于IDLE態(tài),則執(zhí)行隨機接入過程,建立RRC連接和EPS連接。處于RRC連接態(tài)的UE不需要執(zhí)行此步驟。2) 步驟2:通過上行直傳消息發(fā)送NAS消息TRUNKING DEREGISTER REQUEST,其中攜帶有注銷原因值(標準注銷)。3) 步驟3:基站通過上行直傳消息將該NAS消息透傳給集群核心網。4) 步驟45:集群核心網接受終端的集群注

14、銷申請,通過步驟4、5發(fā)送TRUNKING DEREGISTER ACCEPT給UE。3.1.5 終端發(fā)起的關機注銷流程圖7 終端發(fā)起的關機注銷流程流程說明如下:1) 步驟1:如果UE處于IDLE態(tài),則執(zhí)行隨機接入過程,建立RRC連接和EPS連接。處于RRC連接態(tài)的UE不需要執(zhí)行此步驟。2) 步驟2:通過上行直傳消息發(fā)送NAS消息TRUNKING DEREGISTER REQUEST,其中攜帶有注銷原因值(關機注銷)。3) 步驟3:基站通過上行直傳消息將該NAS消息透傳給集群核心網。4) 步驟45:可選地,集群核心網通過步驟4、5發(fā)送TRUNKING DEREGISTER ACCEPT給UE;

15、3.1.6 終端發(fā)起的關機注銷流程(Detach)圖8 終端發(fā)起的關機注銷流程(detach)流程說明如下:1) 步驟1:如果UE處于IDLE態(tài),則執(zhí)行隨機接入過程,建立RRC連接和EPS連接。處于RRC連接態(tài)的UE不需要執(zhí)行此步驟。2) 步驟2:UE通過上行直傳消息發(fā)送NAS消息DETACH REQUEST,并刪除集群上下文。3) 步驟3:基站通過上行直傳消息將該NAS消息透傳給集群核心網。集群核心網接受終端DETACH并刪除集群上下文。3.1.7 網絡發(fā)起的集群注銷流程圖9網絡發(fā)起的集群注銷流程流程說明如下:1) 步驟1:核心網發(fā)起集群注銷過程。如果UE處于IDLE態(tài),核心網需要先尋呼該終

16、端,終端響應尋呼并建立連接。2) 步驟2:核心網通過下行直傳消息發(fā)送NAS消息TRUNKING DEREGISTER REQUEST,消息中攜帶注銷原因值(標準注銷:網絡側去激活集群功能/注銷后需重新發(fā)起注冊:網絡側發(fā)生不可修復的錯誤時需要終端重新注冊/用戶簽約數據被刪除引起的注銷:網絡側刪除該用戶簽約數據)。3) 步驟3:eNB將TRUNKING DEREGISTER REQUEST傳給終端。4) 步驟45:終端接受網絡的集群注銷命令,通過步驟4、5發(fā)送TRUNKING DEREGISTER ACCEPT給集群核心網。3.1.8 調度臺注冊流程圖10調度臺注冊流程流程說明:1) 調度臺向集群

17、核心網發(fā)送SIP(REGISTER)消息發(fā)起注冊過程,消息中攜帶集群業(yè)務標識pttregister,并攜帶Expires:3600頭域,可選攜帶數據查詢指示dataquery字段,該字段指示本次數據請求的類型為“全局查詢”或者“增量查詢”。2) 集群核心網向調度臺發(fā)送SIP(401 Unauthorized)消息,要求進行鑒權,攜帶WWW-Authenticate頭域,以標準SIP摘要的形式發(fā)起認證挑戰(zhàn);3) 調度臺再次發(fā)送SIP(REGISTER)消息到集群核心網,向集群核心網申請業(yè)務注冊,攜帶Authorization 頭域;4) 集群核心網向調度臺發(fā)送SIP(200 OK)消息,注冊成功

18、,攜帶pttregister標識,并可根據步驟1)中SIP(REGISTER)消息的dataquery字段,攜帶調度臺的組信息。3.1.9 調度臺注銷流程圖11調度臺注銷流程流程說明:1) 調度臺發(fā)送SIP(REGISTER)消息到集群核心網,向集群核心網發(fā)起業(yè)務注銷(Expires:0),攜帶集群業(yè)務標識pttregister。2) 集群核心網向調度臺發(fā)送SIP(401 Unauthorized)消息,要求進行鑒權,攜帶WWW-Authenticate頭域,以標準SIP摘要的形式發(fā)起認證挑戰(zhàn);3) 調度臺再次發(fā)送SIP(REGISTER)消息到集群核心網,向集群核心網發(fā)起業(yè)務注銷,攜帶Aut

19、horization 頭域;4) 集群核心網向調度臺發(fā)送SIP(200OK)消息,注銷成功,攜帶pttregister標識。3.2 承載管理3.2.1 專有承載激活圖12 專有承載激活過程流程說明如下:1) 集群核心網向eNodeB發(fā)送專用承載建立請求E-RAB Setup Request消息(包括EPS承載ID、EPS承載QoS以及S1-U的TEID),消息中攜帶一個或多個NAS消息Activate Dedicated EPS Bearer Context Request。2) eNodeB將EPS承載QoS映射到無線承載QoS,然后向UE發(fā)送RRC Connection Reconfigu

20、ration 消息。3) UE向eNodeB發(fā)送RRC Connection Reconfiguration Complete消息,確認無線承載激活。4) eNodeB向EPC發(fā)送E-RAB Setup Response消息來確認承載激活。5) 針對激活的每一個承載,UE的NAS層建立一個Activate Dedicated EPS Bearer Context Accept消息,該消息包括EPS 承載ID,并用UL Information Transfer消息發(fā)送至eNodeB。6) eNodeB收到步驟5的消息后,向集群核心網發(fā)送Uplink NAS Transport消息,消息攜帶Act

21、ivate Dedicated EPS Bearer Context Accept消息。對于激活的每一個承載,步驟5、6均應執(zhí)行一次。3.2.2 核心網發(fā)起的專有承載去激活圖13 核心網發(fā)起的專有承載去激活流程說明如下:1) 集群核心網通過S1AP向eNodeB發(fā)送專用承載去激活請求E-RAB Release Command消息,消息中同時攜帶NAS消息Deactivate EPS Bearer Context Request,該消息包括了去激活的原因以及PTI等參數。2) eNodeB向UE發(fā)送RRC Connection Reconfiguration 消息,內容包括要刪除的EPS Rad

22、io Bearer Identity。消息中同時攜帶NAS消息Deactivate EPS Bearer Context Request。3) UE發(fā)送RRC Connection Reconfiguration Complete消息給eNodeB作為響應。4) eNodeB向集群核心網發(fā)送E-RAB Release Response(EPS Bearer Identity)消息來確認承載去激活。5) UE的 NAS層建立一個Deactivate EPS Bearer Context Accept消息,該消息包括EPS 承載ID。然后UE向eNodeB發(fā)送UL Information Tran

23、sfer消息,消息攜帶該NAS消息。6) eNodeB向集群核心網發(fā)送Uplink NAS Transport消息,消息攜帶Deactivate EPS Bearer Context Accept消息。3.3 語音單呼/可視單呼3.3.1 單呼建立流程 終端發(fā)起的單呼建立圖14終端發(fā)起的單呼建立流程流程說明如下:1) 步驟1a: 如是處于ECM-IDLE態(tài)的UE,需要先通過SERVICE REQUEST流程,和網絡恢復連接。2) 步驟1:主叫UE通過NAS消息CALL REQUEST,通知網絡需要建立全雙工單呼, 攜帶媒體格式,主要包括:Call Type,Call Attrib

24、ute,Called Number,Audio Description(如果Call Type業(yè)務中包含音頻媒體),Video Description(如果Call Type業(yè)務中包含視頻媒體)。3) 步驟2:如被叫為和網絡沒有連接的UE,則核心網通過Trunking Paging通知UE,相關的呼叫到達。4) 步驟3:被叫UE通過SERVICE REQUEST流程,和網絡配合,恢復空口承載以及信令連接。5) 步驟4:核心網通過CALL REQUEST消息,通知被叫UE此次呼叫的相關信息,攜帶媒體格式,主要包括:Call ID,Caller Number,Call Type,Call Attr

25、ibute,Call Priority,Audio Description(如果Call Type業(yè)務中包含音頻媒體),Video Description(如果Call Type業(yè)務中包含視頻媒體)。6) 步驟5:被叫UE通過CALL CONFIRMED消息,通知核心網本UE已收到CALL REQUEST. 攜帶媒體格式,主要包括:Call ID,Audio Description(如果Call Type業(yè)務中包含音頻媒體),Video Description(如果Call Type業(yè)務中包含視頻媒體)。7) 步驟6:網絡通過CALL PROCEEDING,通知主叫媒體格式,主要包括:Call

26、 ID, Call Type,Call Attribute,Priority,Audio Description(如果Call Type業(yè)務中包含音頻媒體),Video Description(如果Call Type業(yè)務中包含視頻媒體)。如果網絡決策,call proceeding與被叫側call request、call confirm無時序關系;如果協(xié)商決定,則有時序關系。8) 步驟7:網絡和被叫UE配合,建立相應的專用承載。9) 步驟8:網絡和主叫UE配合,建立相應的專用承載。10) 步驟910:被叫振鈴,通過網絡,通知主叫UE。11) 步驟11:被叫摘機后,通過CALL CONNECT

27、通知核心網。12) 步驟12:核心網通過CALL CONNECT通知主叫UE,被叫已摘機,可以進行數據傳輸。13) 步驟13:主叫UE反饋CALL CONNECT ACK給核心網,相應CALL CONNECT已收到。14) 步驟14:核心網向被叫UE反饋主叫UE已收到CALLCONNECT。15) 主叫和被叫開始通話。 終端發(fā)起的半雙工單呼建立無應答方式(可選)圖15終端發(fā)起的半雙工單呼建立流程流程說明如下:1) 步驟15:發(fā)起者UE執(zhí)行RRC連接建立流程。UE在連接建立完成消息中攜帶NAS消息,TRUNKING SERVICE REQUEST,其中除了安全信息外,攜帶呼叫請求C

28、ALL REQUEST,用以申請建立一個集群組呼業(yè)務。CALL REQUEST攜帶媒體格式,主要包括:Call Type,Call Attribute,Called Number,Audio Description(如果Call Type業(yè)務中包含音頻媒體),Video Description(如果Call Type業(yè)務中包含視頻媒體)2) 步驟6:基站通過INITIAL UE MESSAGE向核心網發(fā)送初始UE消息,攜帶TRUNKING SERVICE REQUEST。3) 步驟7:核心網和UE之間,通過安全鑒權流程來確定用戶的合法性。4) 步驟8:如被叫為和網絡沒有連接的UE,則核心網通過

29、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業(yè)務中包含音頻媒體),Video Description(如果Call Type業(yè)務中包含視頻媒體)7) 步驟11:被叫U

30、E通過CALL CONFIRMED消息,通知核心網本UE已收到CALL REQUEST。CALL CONFIRMED消息攜帶媒體格式,主要包括:Call ID,Audio Description(如果Call Type業(yè)務中包含音頻媒體),Video Description(如果Call Type業(yè)務中包含視頻媒體)8) 步驟12:網絡和UE配合,建立相應的專用承載。9) 步驟13:核心網發(fā)起觸發(fā)INITIAL CONTEXT SETUP REQUEST給基站,其中,攜帶有核心網給UE建立的專用承載(Qos, TFT)信息,供發(fā)起者上行傳輸使用主被叫時序沒有關系。10) 如果消息13中配置了U

31、E Radio Capability IE,則基站不會發(fā)送消息14 UECapabilityEnquiry消息給UE,即沒有第14-16步過程;否則會觸發(fā)流程1416,UE上報無線能力信息后,基站通過UE CAPABILITY INFO INDICATION上報UE的無線能力信息。11) 步驟1718:eNB執(zhí)行空口安全模式操作,激活對應空口的安全機制。12) 步驟19:eNB通過RRC重配,恢復UE的空口承載,同時,攜帶專用承載建立請求,建立為半雙工單呼使用的專用承載。13) 步驟2021:UE反饋RRC層的配置結果給基站?;就ㄟ^INITIAL CONTEXT SETUP RESPONSE

32、反饋結果給核心網。14) 步驟22:UE通過上行直傳,向核心網反饋NAS層專用承載建立的結果。15) 步驟2324:核心網通過CALL ACCEPT通知發(fā)起者,相應資源已準備完畢,可以進行上行傳輸。UE通過CALL COMPLETE通知核心網,CALL ACCEPT已被UE獲得。CALL ACCEPT消息攜帶媒體格式,主要包括:Call ID,Call Type,Call Attribute,Priority,Floor Status,Audio Description(如果Call Type業(yè)務中包含音頻媒體),Video Description(如果Call Type業(yè)務中包含視頻媒體)。

33、16) 主叫UE獲得話權,開始數據傳輸。17) 步驟25:核心網通過FLOOR INFORM流程,向被叫UE通知當前的話權狀態(tài)。 調度臺發(fā)起的單呼建立圖16調度臺發(fā)起的單呼建立流程流程說明如下:1) 步驟1:調度臺發(fā)送SIP(INVITE)消息,發(fā)起單呼建立。2) 步驟2:核心網向調度臺發(fā)送SIP(100 TRYING)消息響應3) 步驟34:尋呼被叫終端,被叫終端建立RRC連接,僅用于被叫終端處于空閑態(tài)時。對于連接態(tài)被叫終端不需要。4) 步驟5:網絡向被叫終端發(fā)起單呼建立CALL REQUEST消息。CALL REQUEST消息攜帶媒體格式,主要包括:Call ID,Calle

34、r Number,Call Type,Call Attribute,Call Priority,Audio Description(如果Call Type業(yè)務中包含音頻媒體),Video Description(如果Call Type業(yè)務中包含視頻媒體)5) 步驟6:被叫終端發(fā)送Call Confirmed消息響應,攜帶被叫媒體信息,主要包括:Call ID,Audio Description(如果Call Type業(yè)務中包含音頻媒體),Video Description(如果Call Type業(yè)務中包含視頻媒體)6) 步驟7:被叫終端建立專用承載7) 步驟8:被叫終端發(fā)送Alerting消息

35、8) 步驟9:核心網向調度臺發(fā)送SIP(180 RINGING)消息振鈴,可選攜帶給主叫的媒體信息9) 步驟10:被叫終端發(fā)送CALL Connect消息10) 步驟11:核心網向調度臺發(fā)送SIP(200 OK)消息,如果180 RINGING沒有攜帶給主叫的媒體信息,在200 OK攜帶給主叫的媒體信息。如果網絡決策,主被叫無時序關系;如果協(xié)商決定,則有如圖所示的時序關系。11) 步驟12:網絡向被叫終端發(fā)CALL Connect ACK消息響應。12) 步驟13:調度臺向核心網發(fā)送SIP(ACK)消息 調度臺發(fā)起的半雙工單呼建立無應答方式(可選)圖17調度臺發(fā)起的半雙工單呼建立

36、描述流程說明如下:1) 步驟1:調度臺發(fā)送SIP(INVITE)消息,發(fā)起單呼建立。2) 步驟2:核心網回復100 Trying。3) 步驟3:核心網尋呼被叫。4) 步驟4:終端響應尋呼,建立RRC連接。5) 步驟5:網絡向被叫終端發(fā)起單呼建立CALL REQUEST消息。主被叫時序沒有關系。CALL REQUEST消息攜帶媒體格式,主要包括:Call ID,Caller Number,Call Type,Call Attribute,Call Priority,Audio Description(如果Call Type業(yè)務中包含音頻媒體),Video Description(如果Call T

37、ype業(yè)務中包含視頻媒體)6) 步驟6:被叫終端發(fā)送Call Confirmed消息響應。Call Confirmed消息攜帶媒體格式,主要包括:Call ID,Audio Description(如果Call Type業(yè)務中包含音頻媒體),Video Description(如果Call Type業(yè)務中包含視頻媒體)7) 步驟7:核心網向調度臺發(fā)送SIP(200 OK)消息8) 步驟8:被叫終端發(fā)送FLOOR INFORM消息9) 步驟9:調度臺向核心網發(fā)送SIP(ACK)消息 終端發(fā)起單呼呼叫調度臺圖18終端發(fā)起單呼呼叫調度臺流程說明如下:1) 步驟1a: 如是處于ECM-I

38、DLE態(tài)的UE,需要先通過SERVICE REQUEST流程,和網絡恢復連接。2) 步驟1:主叫UE通過NAS消息CALL REQUEST,通知網絡需要建立全雙工單呼。攜帶媒體格式,主要包括:Call Type,Call Attribute,Called Number,Audio Description(如果Call Type業(yè)務中包含音頻媒體),Video Description(如果Call Type業(yè)務中包含視頻媒體)。3) 步驟2:核心網發(fā)送INVITE消息,通知調度臺此次呼叫的相關信息。4) 步驟3:調度臺發(fā)送100 TRYING消息。5) 步驟4:調度臺摘機,發(fā)送180 RINGI

39、NG消息6) 步驟5:網絡側確定UE的媒體信息,通過CALL PROCEEDING,通知主叫UE此次呼叫的協(xié)商結果,主要包括:Call ID, Call Type,Call Attribute,Priority,Audio Description(如果Call Type業(yè)務中包含音頻媒體),Video Description(如果Call Type業(yè)務中包含視頻媒體)7) 步驟6:如果網絡決策媒體信息,網絡和主叫UE配合,建立相應的專用承載(6a)。如果端到端協(xié)商決定,則核心網收到調度臺發(fā)送SIP(200 OK)消息中攜帶的媒體信息后,建立相應的專用承載(6b)。8) 步驟7:核心網向終端發(fā)送

40、PTP Alerting消息振鈴9) 步驟8:調度臺發(fā)送SIP(200 OK)消息,攜帶媒體信息。如果網絡決策,主被叫無時序關系;如果協(xié)商決定,則有如圖所示的時序關系。10) 步驟9:核心網通過CALL CONNECT通知主叫UE,被叫已摘機,可以進行數據傳輸。11) 步驟10:核心網發(fā)送SIP(ACK)消息12) 步驟11:主叫UE反饋CALL CONNECT ACK給核心網,相應CALL CONNECT已收到。13) 主叫和被叫開始通話。3.3.2 單呼釋放流程 終端發(fā)起的單呼釋放圖19終端發(fā)起的單呼釋放流程流程說明如下:1) 步驟1:正在通話的UE1按下掛斷鍵發(fā)起呼叫釋放過

41、程,UE1發(fā)送CALL RELEASE REQUEST消息給eCN2) 步驟2:核心網向UE2發(fā)送CALL RELEASE REQUEST消息。3) 步驟3: UE2向核心網發(fā)送CALL RELEASE RESPONSE消息。4) 步驟4:核心網向UE1發(fā)送CALL RELEASE RESPONSE消息 調度臺發(fā)起的單呼釋放圖20調度臺發(fā)起的單呼釋放流程說明如下:1) 步驟1:調度臺發(fā)送SIP(bye)消息,發(fā)起單呼釋放。2) 步驟2:核心網向UE發(fā)送CALL RELEASE REQUEST消息。3) 步驟3: UE向核心網發(fā)送CALL RELEASE RESPONSE消息。4)

42、 步驟4:核心網向調度臺發(fā)送SIP(200 ok)消息。3.4 語音組呼、可視組呼3.4.1 用戶發(fā)起的組呼建立流程圖21用戶發(fā)起的組呼建立流程說明:上述流程圖為IDLE態(tài)UE觸發(fā)的組呼建立過程。如果組呼發(fā)起者為連接態(tài)UE,則通過NAS直傳消息攜帶CALL REQUEST。流程說明如下:1) 步驟15:發(fā)起組呼的IDLE UE執(zhí)行RRC連接建立流程。UE在連接建立完成消息中攜帶NAS消息TRUNKING SERVICE REQUEST,其中除了安全信息外,攜帶呼叫請求CALL REQUEST(消息中攜帶呼叫類型、呼叫屬性、被叫號碼、媒體信息等),用以申請建立一個集群組呼業(yè)務。2) 步驟6:基站

43、通過INITIAL UE MESSAGE向核心網發(fā)送初始UE消息,攜帶TRUNKING SERVICE REQUEST。3) 步驟7:核心網和UE之間,通過安全鑒權流程來確定用戶的合法性。4) 步驟8:核心網發(fā)起觸發(fā)INITIAL CONTEXT SETUP REQUEST給基站,其中,攜帶有核心網給UE建立的專用承載(Qos, TFT),供發(fā)起者上行傳輸使用。5) 如果消息8中配置了UE Radio Capability IE,則基站不會發(fā)送消息9 UECapabilityEnquiry消息給UE,即沒有第9-11步過程;否則會觸發(fā)流程911,UE上報無線能力信息后,基站通過UE CAPAB

44、ILITY INFO INDICATION上報UE的無線能力信息。6) 步驟1213:eNB執(zhí)行空口安全模式操作,激活對應空口的安全機制。7) 步驟14:eNB通過RRC重配,恢復UE的空口承載。同時,攜帶專用承載建立請求,建立為發(fā)起者初始話權使用的承載。8) 步驟1516:UE反饋RRC層的配置結果給基站?;就ㄟ^INITIAL CONTEXT SETUP RESPONSE反饋給核心網。9) 步驟17:UE通過上行直傳,向核心網反饋NAS層專用承載建立的結果。10) 步驟18:核心網向相關基站發(fā)起群組下行承載的建立。各基站可以并行此過程,也可以和發(fā)起者相關流程并行(步驟817),以及與對調度

45、臺的通知并行(步驟21)。11) 步驟19相關基站發(fā)送Trunking Paging消息,其中攜帶trunkingGroupID,groupPriority,G-RNTI;可選攜帶靜態(tài)資源列表、NAS消息GROUP CALL SETUP INDICATION(Call ID, CallType/MediaType/ServiceType/CallAttribute/CalledNumber/MediaDescription)。如果其中攜帶靜態(tài)資源列表和NAS消息GROUP CALL SETUP INDICATION,則終端收到Trunking Paging后可以直接配置TTCH,開始接收業(yè)務數

46、據。12) 步驟20,基站在TCCH信道上發(fā)送GroupCallConfig,給出群組TTCH的接入層配置參數,其中還包含NAS消息GROUP CALL SETUP INDICATION(攜帶Call ID, CallType/MediaType/ServiceType/CallAttribute/CalledNumber/MediaDescription)。各監(jiān)聽UE收到步驟19/20的空口消息后,可以進行群組業(yè)務的接收。Note 1:步驟18-20為組呼承載建立過程,該過程可以在步驟6后開始執(zhí)行,取決于核心網的實現。13) 步驟21:如果調度臺為被叫,則核心網在收到主叫的Call Requ

47、est消息之后(,通過D接口發(fā)起SIP的Invite 流程,通知調度臺接入該組呼。具體包括以下過程:14) 步驟21a:集群核心網向調度臺發(fā)送SIP(INVITE)消息,通知調度臺進行組呼建立流程,攜帶業(yè)務標識pttcall,呼叫類型calltype,呼叫優(yōu)先級屬性標識PrioAttribute、端到端加密指示e2ee、單雙工指示duplex。15) 步驟21b:被叫調度臺向集群核心網回復SIP(100 Trying)消息;16) 步驟21c:被叫調度臺接受當前呼叫,向集群核心網發(fā)送SIP(200 OK)消息,確認被叫調度臺接聽當前呼叫;攜帶pttcall。17) 步驟21d:集群核心網向被叫

48、調度臺發(fā)送SIP(ACK)消息,確認當前組呼建立成功。18)Note 2:步驟21為呼叫調度臺的過程,該過程可以在步驟6后開始執(zhí)行,取決于核心網的實現。19) 步驟22:在至少一個基站下行承載成功建立后,核心網通過CALL ACCEPT通知發(fā)起者,相應資源已準備完畢,可以進行上行傳輸,消息攜帶呼叫ID、呼叫類型、呼叫屬性、呼叫優(yōu)先級、話權信息、媒體信息等,如果本次呼叫為端到端加密呼叫,還應攜帶加密密鑰。20) 步驟23:UE通過CALL COMPLETE通知核心網,CALL ACCEPT已被UE獲得。21) 步驟24,25:核心網通過FLOOR INFORM流程,向監(jiān)聽UE通知群組的當前話權狀

49、態(tài)。22) 步驟26a/26b:如果調度臺為組呼被叫,核心網向調度臺發(fā)送SIP(INFO)消息,將話權信息通知到DC,攜帶話權通知類型標識pttinfo,話權忙閑指示AlertType,如果當前話權占用,攜帶話權用戶的號碼;調度臺向集群核心網發(fā)送SIP(200(OK))消息,響應集群核心網的話權通知。3.4.2 調度臺發(fā)起的組呼建立流程圖22調度臺發(fā)起的組呼建立流程流程說明如下:調度臺發(fā)起的組呼需要在調度臺與集群核心網之間的D接口增加組呼建立和組呼建議響應消息,涉及SIP信令1、2、7、8,說明如下:1) 步驟1:調度臺發(fā)送SIP(INVITE)消息到集群核心網,請求建立組呼業(yè)務,攜帶業(yè)務標識

50、pttcall,呼叫類型calltype,呼叫優(yōu)先級屬性標識PrioAttribute、端到端加密指示e2ee、單雙工指示duplex;2) 步驟2:集群核心網向主叫調度臺回復SIP(100 Trying)消息,通知主叫的請求正在被處理;3) 步驟7:集群核心網向主叫調度臺發(fā)送SIP(200 OK)消息,通知組呼建立成功并授予調度臺話權,攜帶pttaccept擴展頭域,可選攜帶在線呼叫識別OnlineCallID;4) 步驟8:調度臺向集群核心網發(fā)送SIP(ACK)消息,確認當前組呼建立成功。集群核心網收到調度臺發(fā)送的SIP(ACK)時啟動組呼時長定時器,該定時器用于控制一個組呼的呼叫時長(從

51、組呼建立成功時啟動,到組呼釋放時停止),如果組呼時長定時器超過預設的組呼呼叫時長限制,則核心網可以主動釋放該組呼。下行組呼建立相關流程:5) 步驟3:集群核心網向基站發(fā)送群組尋呼命令。6) 步驟4:集群基站在空口廣播群組尋呼消息。其中攜帶trunkingGroupID,groupPriority,G-RNTI;可選攜帶靜態(tài)資源列表、NAS消息GROUP CALL SETUP INDICATION(Call ID, CallType/MediaType/ServiceType/CallAttribute/CalledNumber/MediaDescription)。如果其中攜帶靜態(tài)資源列表和NA

52、S消息GROUP CALL SETUP INDICATION,則終端收到Trunking Paging后可以直接配置TTCH,開始接收業(yè)務數據。7) 步驟5:集群核心網發(fā)起群組上下文建立過程消息,通知基站建立集群組呼業(yè)務承載。8) 步驟6:基站在TCCH信道上發(fā)送GroupCallConfig,給出群組TTCH的接入層配置參數,其中還包含NAS消息GROUP CALL SETUP INDICATION(攜帶Call ID, CallType/MediaType/ServiceType/CallAttribute/CalledNumber/MediaDescription)。9) 步驟9:集群核

53、心網通過NAS消息發(fā)送話權狀態(tài)指示信息給聽用戶。3.4.3 終端發(fā)起的組呼釋放流程UE B有權釋放組呼,其發(fā)起組呼釋放過程如下:圖23組呼釋放流程流程說明如下:1) 步驟1:如果UE B處于RRC IDLE態(tài),需要先執(zhí)行RRC連接建立過程進入連接態(tài);2) 步驟2:UE B給核心網發(fā)送上行NAS消息組呼釋放請求CALL RELEASE REQUEST,其中攜帶釋放原因;3) 步驟3:核心網對用戶信息進行驗證,確認UE B有組呼釋放權限,并確定執(zhí)行組呼釋放。4) 步驟4:核心網發(fā)送NAS消息CALL RELEASE RESPONSE,回復UE B組呼釋放響應。5) 步驟5:如果此時UE A擁有話權

54、,可選的,核心網發(fā)送下行直傳消息FLOOR RELEASE給UE A,執(zhí)行話權釋放過程。6) 步驟6: 可選的,如果收到步驟5,UE A通過上行直傳消息回復FLOOR RELEASE ACK。7) 步驟7:UE A與網絡執(zhí)行專用承載釋放過程。8) 步驟8:核心網和基站釋放組呼承載。9) 步驟9:基站發(fā)送GroupCallRelease消息,其中攜帶NAS消息:GROUP CALL RELEASE INDICATION,其中攜帶組呼釋放原因。注:網絡發(fā)起的組呼釋放過程從第8步開始,包括步驟89;如果當前組呼有用戶擁有話權,則還包括第5-7步。如果網絡側以話權空閑時間為條件觸發(fā)組呼釋放,則網絡側需

55、要在某個用戶釋放話權后,置起話權空閑定時器,如果在話權空閑定時器運行期間,有用戶獲得話權,則該定時器置零;一旦話權空閑定時器達到門限,網絡側則觸發(fā)組呼釋放過程。3.4.4 調度臺發(fā)起的組呼釋放流程圖24組呼釋放流程流程說明如下:1) 步驟1:如果調度臺決定釋放某個組,調度臺向集群核心網發(fā)送SIP(BYE)消息,申請釋放組呼業(yè)務,攜帶呼叫釋放指示標識pttrelease、釋放原因cause;2) 步驟2:核心網對調度臺的釋放請求進行驗證,確認調度臺有組呼釋放權限,并確定執(zhí)行組呼釋放。3) 步驟3:集群核心網向調度臺發(fā)送SIP(200(OK))消息,確認當前組呼釋放成功。4) 步驟4:如果此時UE

56、 A擁有話權,可選的,核心網發(fā)送下行直傳消息FLOOR RELEASE給UE A,執(zhí)行話權釋放過程。5) 步驟5: 可選的,如果收到步驟4,UE A通過上行直傳消息回復FLOOR RELEASE ACK。6) 步驟6:UE A與網絡執(zhí)行專用承載釋放過程。7) 步驟7:核心網和基站釋放組呼承載。8) 步驟8:基站發(fā)送GroupCallRelease消息,其中攜帶NAS消息:GROUP CALL RELEASE INDICATION,其中攜帶組呼釋放原因。3.4.5 組呼建立過程補充場景(可選) 組呼已建立,用戶發(fā)起該組呼建立,用戶所在小區(qū)已經建立組呼資源UE C發(fā)起組呼建立過程(同時申請話權),此時組呼業(yè)務已經建立,并且UE C所在小區(qū)已經建立了組呼相關信道。圖25組呼建立流程(補充場景1)流程說明如下:1) 集群核心網收到UE C的組呼建立請求時判斷該組呼已經建立,并且該小區(qū)已經建立了組呼相關信道,則集群核心網通過NAS消息將話權結果發(fā)給終端,如授予該用戶話權,或者將該用戶至于話權排隊隊列,或者直接拒絕該用戶的話權申請。2) 網絡回復Call Accept消息給UE C,通過IE指示如下幾種結果:l 如果直接授予UE C話權,網絡通過IE告知其獲得話權。UE C完成承載

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論