IMT-2020(5G)推进组 5G-Advanced卫星网络增强技术专题报告_第1页
IMT-2020(5G)推进组 5G-Advanced卫星网络增强技术专题报告_第2页
IMT-2020(5G)推进组 5G-Advanced卫星网络增强技术专题报告_第3页
IMT-2020(5G)推进组 5G-Advanced卫星网络增强技术专题报告_第4页
IMT-2020(5G)推进组 5G-Advanced卫星网络增强技术专题报告_第5页
已阅读5页,还剩60页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

2 3 5 7 7 28 3在标准化进展方面,ITU、3GPP和3GPP在非地面网络(NTN)标准化工作中成果显著,Release19关注再生19还引入了面向IoT终端的存储与转发服务,以提供时延不敏感的业务通信。前,Release20进一步聚焦低通量高轨卫星接入场景的语并存。天基网络中的卫星,可以采用3GPP协议或者非3GPP协议接入地面信关定/移动多连接终端接入卫星网络或地基网络并可使用5G通信业务。已在轨工作约9000颗,服务覆盖全球100多个国家与地区。截止到2025年8月份,用户数约达700万,成为全球最大卫星互联网系统。亚马逊Kuiper项目星座,分别部署在500km以下的极低轨道和1145km的近地轨道。"千帆星座"4分三个阶段建设1.5万颗星的手机直连多业务融合系统,预计到2025年底实现648颗卫星提供区域网络覆盖,到2027年实现648颗卫星提供全球网络覆盖,到2030年底实现1.5万颗卫星提供手机直连多业务融合服务。天通一号系统作52.典型的业务场景需求NTN网络在5G-Advanced系统中需要支持多种化部署、全场景应用的通信服务需求。根据3GPPRelease20服务需求的标准,高轨卫星IMS语音通信场景是NTN网络的重要应用卫星接入具有约540ms的往返传播时延,这对传统地面蜂窝网络的语音通信流程提出了显著挑战。系统需要在尽可能保持现有IMS架构和考虑终端兼容性的盖的环境中具有重要价值。系统需要支持语音、消息、数据等多种业务类型的UE间通信。UE间直连通信还可以作为应急情况下的备用通信手段,在地面网多轨道卫星网络场景体现了NTN系统的复杂性和灵活性。LEO卫星具有低时延优势但覆盖时间有限,GEO卫星提供稳定的大范围够在极端条件下维持基本通信服务。系统需要支持MPS(多媒体优先服务)和MCS(关键任务服务)等优先级通信机制,确保应急响应、救援指挥等关键通通信、位置服务、视频回传等,也需要在卫星环境下得6广播组播服务场景充分利用了卫星通信的大覆盖优势。单颗GE播架构,优化内容缓存和分发策略。卫星广播/组播服务在体育赛事直播、新闻这些典型业务场景体现了NTN在5G-Advanced系统中的多元化应用价值,73.面向卫星接入网络通信增强技术的适配优化。支持非IMS业务UE间直连通信增强,重点考虑卫星动态拓扑的3.1高轨卫星接入的IMS语音为支持IMS语音服务,系统需针对IMS信令和语音数据流提供不同的下图3.1.1-1展示了NB-IoTNTN连接至EPC的逻辑架构,其中这些承载8示。此体系结构包括一个专门用于传输语音数据包流(SRBx)的新SRIMS信令SDF与语音数据包流在时延和可靠性上有不同需求。语音数据流不采用RLCAM确认方式,而IMS信令使用RLCAM,因此语音数据需通9通过GEO卫星支持NB-IoTNTN语音流量时,数据速率和呼叫建立时间因然而,非IPPDN类型不再能用IP5元组(源/目标IP、端口和协议)进行NAS层:新消息使开销减至3字节,表3.1.1-1对各协议层的开销进行了归纳,并列出了总开销的最佳情形与最协议层描述最佳情况最差情况评论/影响MAC层每个TBS的单个MACPDU规范中支持。RLC层TM或UM0(TM)1B(UM)0字节需要规范支持SRB的RLCTM/UM。RRC层NASPDU的RRC封装0NAS层NAS消息开销0B3BRel-19中的CTWG1工作将NASOH减少到3字节。NAS安全MAC和NAS1B时需要MAC抑制。IP/UDP/RTP3B-30B对于非IPPDN类型:1B用于RTPSN。对于IPPDN类型:RoHC的3B。RoHC上下文(重新)建立期间的30B。总开销3B14B-41B影响开销的关键因素:-MAC(完整性保护)抑制。-IP与非IPPDN类型。-对于IPPDN类型:RoHC上下文(重新)建立期间的RoHCOH。-通过S1-AP进行SRB识-通过SRBx预协商NASPDU大小。开销数据速率由数据包速率决定。例如,每个数据包开销为3B时,若每UE与MME的能力协商流程设计:UE在Attach/TAU请求中通过"Voice"voice-centric"来指示对NB-IoT上IMS语音的支持。MME验证UE订阅数据中是否允许使用NB-IoT(GEO)上的IM可采用预配置的IMS专用APN建立PDN连接,该APN专门配置用于NB-IoT(GEO)语音呼叫服务。考虑到NB-IoTRAT的技术限制和GEO卫星的高的交互遵循标准Rx接口规范,通过策略控新或资源预留。在网络实体影响方面,HSS需要支持订阅数据指示是否允许IMS语音overPCRF需要基于NB-IoTNTNRAT类型做出相应的策略决策。针对IMS信令和语音数据的不同传输需求,有三种承载管理设计方案,针信令和语音数据。该方案的核心技术是承载修改程序的语音呼叫流量资源预留请求时,考虑跳过专用GBR承载分配,或在需要时对于NB-IoTRAT限制不支持专用EPS承载和GBR承载,该策略充分利用了现有语音支持模式,是目前标准化程度最高的IP技术方承载传输,语音数据通过专用IP承载传输,完全兼容现有IMS网络架构。该策略提供了三种专用承载优化设计:第一种设计中,P-GW在呼叫建立过程中通过专用承载修改程序更新TFT;第三种设计中,MME选择具有预配置TFT信息的P-GW,基于运营商策略确定专用EPS承载的上行和下单个IMSAPNPDN连接配置两个不同类型的EPS承载:默认承载用于IP类型的IMS信令传输,专用承载用于非IP类型的语音数据传输。UE需要在Attach语音数据传输是各方案的核心技术,主要采用成熟的IP技术路线,同时也包括完整的IP层处理,支持成熟的RoHC压缩技术降低头部开销。在RoHC上开销控制能力。该设计的优势在于技术成熟、对IMS网络实体无影响、支持标传输结合RoHC压缩技术期待能够较好地满足带宽需求。在网络稳定状态下,Non-IP传输技术探索作为一种备选技术研究,通过协议转换机制尝试减少协议开销。该技术设计要求UE/PGW承担协议转换功能,在NIDD格式与标准显著挑战。由于高轨卫星链路存在高达540ms的往返传播时延和受限的链路带宽,传统的按需建立机制会导致IMS语音呼叫建立过程明显延长,严重影响用户体验。针对这一问题,可以引入专用承载预建立机制,即在PDU会话建立阶在具体实现上,在注册流程中RAN指示卫星接入类型,即RATType标识GEO卫星的高时延和NB-IoT的窄带宽特性对IMS协议流程提出了严峻挑战,需要从流程、消息和架构多个层面进行优化。在进行IMS语音业务时,可在高延迟、有限带宽的NB-IoTGEO卫星网络场景下,传统的IMS语音呼本章节提出基于网络侧功能增强的优化思路,其核心在于引入背靠背用户代理在IMS架构中,P-CSCF(代理-呼叫会话控制功能)和AS(应用用于不同场景的优化方案,这两个方案的核心区分点在于由哪个网络实体传输延迟(约250ms单向)和有限的链路带宽,导致传统的IMS语音呼叫建立5.7a,无先决条件)虽能减少往返次数,但存在媒体建立与用户接听不同步的风险,可能导致被叫用户已开始说话而主叫方因承载未建提出一种通过网络侧功能增强以适配不同终端能力的优化方案,采用类似络侧(P-CSCF)的判断和功能增强(扮演B2BUA来解决不同终端能力(是的终端在通过NB-IoTGEO接入时,需在信令中表明其能力(如不携带场景下,被叫UE无法理解或支持简化流程。为解决此问题,主叫侧的P-CSCF(P-CSCFA)将扮演背靠背用户代理(B2发送给UEA,使UEA能尽早开始资源预留并播放回铃音。被叫侧执行标准完主叫UEA按标准流程发起INVITE(可能包含Precondition),被叫UEB的网络接入信息(NB-IoTGEO)可通过信令卫星UE发起的会话流程简化(AS作为B2BUA)ASASTerminating3.QoSAuthorizationandfortranscodingtranscondingcodecX--AGEO卫星接入的NB-IoTUE(A)决定在会话中使用低数据速率音频编解码3.P-CSCF检测到UE是通过NB-IoT(GEO)连接的。为了减少呼叫建立时间,P-CSCF会触发EPS的QoS授权和资源预留。可以为语音流建立5.AS决定触发UE(A)的主动转码。AS触发相关媒体功能(例如7.AS和终端网络/UE(B)交换SDPOffer/Response以进行媒体编解码卫星UE终止会话流程(AS作为B2BUA)v7.2商媒体编解码器。Codec-A最终在A15.UE将启动此会话的媒体流。UE(A)和MF/MRF之间的媒体流以编解AS在IMS架构中本身就被设计为(接入网关)完成媒体面的编解码B2BUA(例如,用于多方会议、语音信箱等业务),因此其行为符合突破了标准中P-CSCF主要作为无状态/有状态代理的角色定义,需要对其进行功能增强以支持完整的B2BUA行B2BUA行为需要前后端网络单着简化流程可能需要在ISC接口和Mw接口上也得到支持,影响2.依赖MRF/MF(媒体资源功能/持为海量卫星UE发起的呼叫进行动态、高效的媒体资源分配和3.AS及对应的MG/MRF需具备GEO接入侧无QoS保障且缺少在高时延、低带宽的GEO卫星语音通信环境下,为提升可在IMS网络侧引入信元处理机制,例如由P-CSCF启用上行信元填充策略与Sigcom机制利用其状态缓存与字典压缩能力,对SIP消息中冗余度较高的结构的要求,来确定哪些SIP信元、哪些SDP属性行是必须要携带的。在实际部署wheremmmmmmRo--moo---moo**-***mmmmmmmmmmmmRmmmmmmmmmmmmRmmmmmmmmmmmm(1):Headerfiel(2):Copiedfromtherequesttotherespon根据IETFRFC4566,在SDP中,下列属性行必须要携带:v=(protocolversion)o=(originatorandsessionidentifier)s=(sessionname)c=(connectioninformation)t=(timethesessionisactive)m=(medianameandtransportaddress)a=*(zeroormoremediaattributelines)信元说明Call-IDUE必带From-tagUE必带ContactUE仅携带SIPURI,Feature-Caps由P-CSF添加Supported由P-CSCF添加Allow由P-CSCF添加Max-Forward由P-CSCF添加ViaUE必带Security-Client启用IPSec时,UE携带Security-Verify启用IPSec时,UE携带Accept由P-CSCF添加P-Access-Network-InfoP-CSCF识别卫星接入,从而启用填充策略,若P-CSCF识别星上UPF分配的UEIP地址,则可不携带Expires由P-CSCF添加在UE发起SIPINVITE时,则UE可以进一步省略前述已提供的信元(如初始必带信元),省略的信元可进一步由P-CSCF添加:信元说明Call-IDFrom-tagTo-tagContactUE仅携带SIPURI,Feature-Caps由P-CSCF添加SupportedAllowMax-ForwardViaP-Preferred-Identity缺省不带,P-CSCF从From获取PUIRoute初始SIPINVITE中UE不携带,话内SIP请求,UE携带Record-Route转换的RouteRecord-Route初始SIPINVITE中UE不携带Min-SESession-ExpiresP-Preferred-ServiceP-Early-MediaAccept-ContactSecurity-Client启用IPSec时,UE携带Security-Verify启用IPSec时,UE携带AcceptP-Access-Network-Info由P-CSCF添加,可根据前述缓存的消息填充SDP中属性字段说明o行的sessionId、versionIdUE填写SDP时,该字段可以缩短长度。o行的ip地址UE填写SDP时,该字段可以固定填写s=-。UE填写SDP时,只携带一个c行。UE填写SDP时,v行不带b行,只保留m行下的b行。precondition参数不考虑precondition,UE不填写precondition参数。SDP的a=sendrecvUE填写SDP时,不填写SDP的a=sendrecv。一套简化的SIP定时器管理方案,通过动态调整关键定时器值,显著提升VoG方案的核心思想是预先定义两套SIP定时器配置:地面默认配置和GEO专其中PANI头指示RAT类型为GEONB-IoT。UE根据本地配置或网络指也是GEO接入,则其已在注册时启用GEO配置,双方使用GEO定时器交互。若MTUE是地面接入,则其服务IMS网元可根据收到的主叫RAT类型信息,GEO端的慢响应而超时)。呼叫双方基于调整后的长定时器进行信令交互,有在覆盖范围广、资源受限的GEONB-IoTNTN环境中,保障紧急呼叫的可必须确保UE能获取其实际所在国家/地区的正确紧方案的核心在于网络侧根据UE的实时地理位置(国家码MCC)动态提供并更在初始配置阶段,UE在附着请求或跟踪区更新请求中,向MME上报其粗),建立。若UE未正确识别紧急呼叫,P-CSCF也可基于运营商策略进行检测。检测后,P-CSCF可选择拒绝会话并要求UE重新发起,以便UE发起紧急呼叫流该方案通过基于实时地理位置的动态紧急号码推送机制,核心解决了GEO紧急呼叫必须尽可能提供主叫方位置信息,这对具体技术方案包括UE通过NAS安全模式命令程序向MME报告粗略位置中向IMS核心网报告。当IMS核心网需要验证或获取额外位置信息时,可以通的QoS要求,如果之前获取的粗略位置满足要求则直接返回,否则与E-SMLC交互进行位置信息验证,通过将GNSS信息与粗略位置进行比对来验证GNSS测到紧急情况时需要复用EPC-NI-LR程序的基本逻辑,但对于NB-IoTGEO接入场景,MME通过NAS安全模式命令程序获取UE位置而不是向E-SMLC发EMERGENCY_CALL_RELEASE事件。整体方案可复用现有的位置服务框架,通过适配NB-IoTGEO特有的约束条件来实现紧急服务的位语音媒体流和IMS信令统一采用NB-IoT(GEO)用户面承载,通过DRB与S1-U进行传输,不再依赖控制面数据通道IMS语音信令和媒体共用同一个IPPDN连接,UE在该PDN连接建语音媒体承载以基于IP的传输为主,结合头压缩技术在NB-Io基于SIP语音信令呼叫流程的精简与优化可以和消息简化/压缩共部署3.2非IMS业务的UE-Sat-UE增强),UE-Sat-UE增强,可将GEO卫星UE-to-UE本地通信机制扩展至NGSO态性带来的5GLAN服务连续性挑战,实现卫星上UPF的本地流量切换而无需组其他成员相同时继续星上本地切换;通过ISL可达其他成员卫星时经N19/N6隧道转发流量,卫星变更过程中支持切换本地交换模式和地面转发模式。服此外,可以考虑在5GVN组数据中新增例如"UE-SAT-UEcommunicationindication"参数,使SMF能够基于DNN、S-NSSAI和卫星信息明确识别支持UE-SAT-UE通信的5GVN组,并对非卫星接入UE的此类

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论