2 3 5 7 7 28 3在標(biāo)準(zhǔn)化進(jìn)展方面，ITU、3GPP和3GPP在非地面網(wǎng)絡(luò)（NTN）標(biāo)準(zhǔn)化工作中成果顯著，Release19關(guān)注再生19還引入了面向IoT終端的存儲(chǔ)與轉(zhuǎn)發(fā)服務(wù)，以提供時(shí)延不敏感的業(yè)務(wù)通信。前，Release20進(jìn)一步聚焦低通量高軌衛(wèi)星接入場景的語并存。天基網(wǎng)絡(luò)中的衛(wèi)星，可以采用3GPP協(xié)議或者非3GPP協(xié)議接入地面信關(guān)定/移動(dòng)多連接終端接入衛(wèi)星網(wǎng)絡(luò)或地基網(wǎng)絡(luò)并可使用5G通信業(yè)務(wù)。已在軌工作約9000顆，服務(wù)覆蓋全球100多個(gè)國家與地區(qū)。截止到2025年8月份，用戶數(shù)約達(dá)700萬，成為全球最大衛(wèi)星互聯(lián)網(wǎng)系統(tǒng)。亞馬遜Kuiper項(xiàng)目星座，分別部署在500km以下的極低軌道和1145km的近地軌道。"千帆星座"4分三個(gè)階段建設(shè)1.5萬顆星的手機(jī)直連多業(yè)務(wù)融合系統(tǒng)，預(yù)計(jì)到2025年底實(shí)現(xiàn)648顆衛(wèi)星提供區(qū)域網(wǎng)絡(luò)覆蓋，到2027年實(shí)現(xiàn)648顆衛(wèi)星提供全球網(wǎng)絡(luò)覆蓋，到2030年底實(shí)現(xiàn)1.5萬顆衛(wèi)星提供手機(jī)直連多業(yè)務(wù)融合服務(wù)。天通一號系統(tǒng)作52.典型的業(yè)務(wù)場景需求NTN網(wǎng)絡(luò)在5G-Advanced系統(tǒng)中需要支持多種化部署、全場景應(yīng)用的通信服務(wù)需求。根據(jù)3GPPRelease20服務(wù)需求的標(biāo)準(zhǔn)，高軌衛(wèi)星IMS語音通信場景是NTN網(wǎng)絡(luò)的重要應(yīng)用衛(wèi)星接入具有約540ms的往返傳播時(shí)延，這對傳統(tǒng)地面蜂窩網(wǎng)絡(luò)的語音通信流程提出了顯著挑戰(zhàn)。系統(tǒng)需要在盡可能保持現(xiàn)有IMS架構(gòu)和考慮終端兼容性的蓋的環(huán)境中具有重要價(jià)值。系統(tǒng)需要支持語音、消息、數(shù)據(jù)等多種業(yè)務(wù)類型的UE間通信。UE間直連通信還可以作為應(yīng)急情況下的備用通信手段，在地面網(wǎng)多軌道衛(wèi)星網(wǎng)絡(luò)場景體現(xiàn)了NTN系統(tǒng)的復(fù)雜性和靈活性。LEO衛(wèi)星具有低時(shí)延優(yōu)勢但覆蓋時(shí)間有限，GEO衛(wèi)星提供穩(wěn)定的大范圍夠在極端條件下維持基本通信服務(wù)。系統(tǒng)需要支持MPS（多媒體優(yōu)先服務(wù)）和MCS（關(guān)鍵任務(wù)服務(wù)）等優(yōu)先級通信機(jī)制，確保應(yīng)急響應(yīng)、救援指揮等關(guān)鍵通通信、位置服務(wù)、視頻回傳等，也需要在衛(wèi)星環(huán)境下得6廣播組播服務(wù)場景充分利用了衛(wèi)星通信的大覆蓋優(yōu)勢。單顆GE播架構(gòu)，優(yōu)化內(nèi)容緩存和分發(fā)策略。衛(wèi)星廣播/組播服務(wù)在體育賽事直播、新聞這些典型業(yè)務(wù)場景體現(xiàn)了NTN在5G-Advanced系統(tǒng)中的多元化應(yīng)用價(jià)值，73.面向衛(wèi)星接入網(wǎng)絡(luò)通信增強(qiáng)技術(shù)的適配優(yōu)化。支持非IMS業(yè)務(wù)UE間直連通信增強(qiáng)，重點(diǎn)考慮衛(wèi)星動(dòng)態(tài)拓?fù)涞?.1高軌衛(wèi)星接入的IMS語音為支持IMS語音服務(wù)，系統(tǒng)需針對IMS信令和語音數(shù)據(jù)流提供不同的下圖3.1.1-1展示了NB-IoTNTN連接至EPC的邏輯架構(gòu)，其中這些承載8示。此體系結(jié)構(gòu)包括一個(gè)專門用于傳輸語音數(shù)據(jù)包流（SRBx）的新SRIMS信令SDF與語音數(shù)據(jù)包流在時(shí)延和可靠性上有不同需求。語音數(shù)據(jù)流不采用RLCAM確認(rèn)方式，而IMS信令使用RLCAM，因此語音數(shù)據(jù)需通9通過GEO衛(wèi)星支持NB-IoTNTN語音流量時(shí)，數(shù)據(jù)速率和呼叫建立時(shí)間因然而，非IPPDN類型不再能用IP5元組（源/目標(biāo)IP、端口和協(xié)議）進(jìn)行NAS層：新消息使開銷減至3字節(jié)，表3.1.1-1對各協(xié)議層的開銷進(jìn)行了歸納，并列出了總開銷的最佳情形與最協(xié)議層描述最佳情況最差情況評論/影響MAC層每個(gè)TBS的單個(gè)MACPDU規(guī)范中支持。RLC層TM或UM0（TM）1B（UM）0字節(jié)需要規(guī)范支持SRB的RLCTM/UM。RRC層NASPDU的RRC封裝0NAS層NAS消息開銷0B3BRel-19中的CTWG1工作將NASOH減少到3字節(jié)。NAS安全MAC和NAS1B時(shí)需要MAC抑制。IP/UDP/RTP3B-30B對于非IPPDN類型：1B用于RTPSN。對于IPPDN類型：RoHC的3B。RoHC上下文（重新）建立期間的30B?？傞_銷3B14B-41B影響開銷的關(guān)鍵因素：-MAC（完整性保護(hù)）抑制。-IP與非IPPDN類型。-對于IPPDN類型：RoHC上下文（重新）建立期間的RoHCOH。-通過S1-AP進(jìn)行SRB識-通過SRBx預(yù)協(xié)商N(yùn)ASPDU大小。開銷數(shù)據(jù)速率由數(shù)據(jù)包速率決定。例如，每個(gè)數(shù)據(jù)包開銷為3B時(shí)，若每UE與MME的能力協(xié)商流程設(shè)計(jì)：UE在Attach/TAU請求中通過"Voice"voice-centric"來指示對NB-IoT上IMS語音的支持。MME驗(yàn)證UE訂閱數(shù)據(jù)中是否允許使用NB-IoT(GEO)上的IM可采用預(yù)配置的IMS專用APN建立PDN連接，該APN專門配置用于NB-IoT(GEO)語音呼叫服務(wù)?？紤]到NB-IoTRAT的技術(shù)限制和GEO衛(wèi)星的高的交互遵循標(biāo)準(zhǔn)Rx接口規(guī)范，通過策略控新或資源預(yù)留。在網(wǎng)絡(luò)實(shí)體影響方面，HSS需要支持訂閱數(shù)據(jù)指示是否允許IMS語音overPCRF需要基于NB-IoTNTNRAT類型做出相應(yīng)的策略決策。針對IMS信令和語音數(shù)據(jù)的不同傳輸需求，有三種承載管理設(shè)計(jì)方案，針信令和語音數(shù)據(jù)。該方案的核心技術(shù)是承載修改程序的語音呼叫流量資源預(yù)留請求時(shí)，考慮跳過專用GBR承載分配，或在需要時(shí)對于NB-IoTRAT限制不支持專用EPS承載和GBR承載，該策略充分利用了現(xiàn)有語音支持模式，是目前標(biāo)準(zhǔn)化程度最高的IP技術(shù)方承載傳輸，語音數(shù)據(jù)通過專用IP承載傳輸，完全兼容現(xiàn)有IMS網(wǎng)絡(luò)架構(gòu)。該策略提供了三種專用承載優(yōu)化設(shè)計(jì)：第一種設(shè)計(jì)中，P-GW在呼叫建立過程中通過專用承載修改程序更新TFT；第三種設(shè)計(jì)中，MME選擇具有預(yù)配置TFT信息的P-GW，基于運(yùn)營商策略確定專用EPS承載的上行和下單個(gè)IMSAPNPDN連接配置兩個(gè)不同類型的EPS承載：默認(rèn)承載用于IP類型的IMS信令傳輸，專用承載用于非IP類型的語音數(shù)據(jù)傳輸。UE需要在Attach語音數(shù)據(jù)傳輸是各方案的核心技術(shù)，主要采用成熟的IP技術(shù)路線，同時(shí)也包括完整的IP層處理，支持成熟的RoHC壓縮技術(shù)降低頭部開銷。在RoHC上開銷控制能力。該設(shè)計(jì)的優(yōu)勢在于技術(shù)成熟、對IMS網(wǎng)絡(luò)實(shí)體無影響、支持標(biāo)傳輸結(jié)合RoHC壓縮技術(shù)期待能夠較好地滿足帶寬需求。在網(wǎng)絡(luò)穩(wěn)定狀態(tài)下，Non-IP傳輸技術(shù)探索作為一種備選技術(shù)研究，通過協(xié)議轉(zhuǎn)換機(jī)制嘗試減少協(xié)議開銷。該技術(shù)設(shè)計(jì)要求UE/PGW承擔(dān)協(xié)議轉(zhuǎn)換功能，在NIDD格式與標(biāo)準(zhǔn)顯著挑戰(zhàn)。由于高軌衛(wèi)星鏈路存在高達(dá)540ms的往返傳播時(shí)延和受限的鏈路帶寬，傳統(tǒng)的按需建立機(jī)制會(huì)導(dǎo)致IMS語音呼叫建立過程明顯延長，嚴(yán)重影響用戶體驗(yàn)。針對這一問題，可以引入專用承載預(yù)建立機(jī)制，即在PDU會(huì)話建立階在具體實(shí)現(xiàn)上，在注冊流程中RAN指示衛(wèi)星接入類型，即RATType標(biāo)識GEO衛(wèi)星的高時(shí)延和NB-IoT的窄帶寬特性對IMS協(xié)議流程提出了嚴(yán)峻挑戰(zhàn)，需要從流程、消息和架構(gòu)多個(gè)層面進(jìn)行優(yōu)化。在進(jìn)行IMS語音業(yè)務(wù)時(shí)，可在高延遲、有限帶寬的NB-IoTGEO衛(wèi)星網(wǎng)絡(luò)場景下，傳統(tǒng)的IMS語音呼本章節(jié)提出基于網(wǎng)絡(luò)側(cè)功能增強(qiáng)的優(yōu)化思路，其核心在于引入背靠背用戶代理在IMS架構(gòu)中，P-CSCF（代理-呼叫會(huì)話控制功能）和AS（應(yīng)用用于不同場景的優(yōu)化方案，這兩個(gè)方案的核心區(qū)分點(diǎn)在于由哪個(gè)網(wǎng)絡(luò)實(shí)體傳輸延遲（約250ms單向）和有限的鏈路帶寬，導(dǎo)致傳統(tǒng)的IMS語音呼叫建立5.7a,無先決條件）雖能減少往返次數(shù)，但存在媒體建立與用戶接聽不同步的風(fēng)險(xiǎn)，可能導(dǎo)致被叫用戶已開始說話而主叫方因承載未建提出一種通過網(wǎng)絡(luò)側(cè)功能增強(qiáng)以適配不同終端能力的優(yōu)化方案，采用類似絡(luò)側(cè)（P-CSCF）的判斷和功能增強(qiáng)（扮演B2BUA來解決不同終端能力（是的終端在通過NB-IoTGEO接入時(shí)，需在信令中表明其能力（如不攜帶場景下，被叫UE無法理解或支持簡化流程。為解決此問題，主叫側(cè)的P-CSCF(P-CSCFA)將扮演背靠背用戶代理（B2發(fā)送給UEA，使UEA能盡早開始資源預(yù)留并播放回鈴音。被叫側(cè)執(zhí)行標(biāo)準(zhǔn)完主叫UEA按標(biāo)準(zhǔn)流程發(fā)起INVITE（可能包含Precondition）,被叫UEB的網(wǎng)絡(luò)接入信息（NB-IoTGEO）可通過信令衛(wèi)星UE發(fā)起的會(huì)話流程簡化（AS作為B2BUA）ASASTerminating3.QoSAuthorizationandfortranscodingtranscondingcodecX--AGEO衛(wèi)星接入的NB-IoTUE（A）決定在會(huì)話中使用低數(shù)據(jù)速率音頻編解碼3.P-CSCF檢測到UE是通過NB-IoT（GEO）連接的。為了減少呼叫建立時(shí)間，P-CSCF會(huì)觸發(fā)EPS的QoS授權(quán)和資源預(yù)留?？梢詾檎Z音流建立5.AS決定觸發(fā)UE（A）的主動(dòng)轉(zhuǎn)碼。AS觸發(fā)相關(guān)媒體功能（例如7.AS和終端網(wǎng)絡(luò)/UE（B）交換SDPOffer/Response以進(jìn)行媒體編解碼衛(wèi)星UE終止會(huì)話流程（AS作為B2BUA）v7.2商媒體編解碼器。Codec-A最終在A15.UE將啟動(dòng)此會(huì)話的媒體流。UE（A）和MF/MRF之間的媒體流以編解AS在IMS架構(gòu)中本身就被設(shè)計(jì)為（接入網(wǎng)關(guān)）完成媒體面的編解碼B2BUA（例如，用于多方會(huì)議、語音信箱等業(yè)務(wù)），因此其行為符合突破了標(biāo)準(zhǔn)中P-CSCF主要作為無狀態(tài)/有狀態(tài)代理的角色定義，需要對其進(jìn)行功能增強(qiáng)以支持完整的B2BUA行B2BUA行為需要前后端網(wǎng)絡(luò)單著簡化流程可能需要在ISC接口和Mw接口上也得到支持，影響2.依賴MRF/MF（媒體資源功能/持為海量衛(wèi)星UE發(fā)起的呼叫進(jìn)行動(dòng)態(tài)、高效的媒體資源分配和3.AS及對應(yīng)的MG/MRF需具備GEO接入側(cè)無QoS保障且缺少在高時(shí)延、低帶寬的GEO衛(wèi)星語音通信環(huán)境下，為提升可在IMS網(wǎng)絡(luò)側(cè)引入信元處理機(jī)制，例如由P-CSCF啟用上行信元填充策略與Sigcom機(jī)制利用其狀態(tài)緩存與字典壓縮能力，對SIP消息中冗余度較高的結(jié)構(gòu)的要求，來確定哪些SIP信元、哪些SDP屬性行是必須要攜帶的。在實(shí)際部署wheremmmmmmRo--moo---moo**-***mmmmmmmmmmmmRmmmmmmmmmmmmRmmmmmmmmmmmm(1):Headerfiel(2):Copiedfromtherequesttotherespon根據(jù)IETFRFC4566，在SDP中，下列屬性行必須要攜帶：v=(protocolversion)o=(originatorandsessionidentifier)s=(sessionname)c=(connectioninformation)t=(timethesessionisactive)m=(medianameandtransportaddress)a=*(zeroormoremediaattributelines)信元說明Call-IDUE必帶From-tagUE必帶ContactUE僅攜帶SIPURI，F(xiàn)eature-Caps由P-CSF添加Supported由P-CSCF添加Allow由P-CSCF添加Max-Forward由P-CSCF添加ViaUE必帶Security-Client啟用IPSec時(shí)，UE攜帶Security-Verify啟用IPSec時(shí)，UE攜帶Accept由P-CSCF添加P-Access-Network-InfoP-CSCF識別衛(wèi)星接入，從而啟用填充策略，若P-CSCF識別星上UPF分配的UEIP地址，則可不攜帶Expires由P-CSCF添加在UE發(fā)起SIPINVITE時(shí)，則UE可以進(jìn)一步省略前述已提供的信元（如初始必帶信元），省略的信元可進(jìn)一步由P-CSCF添加：信元說明Call-IDFrom-tagTo-tagContactUE僅攜帶SIPURI，F(xiàn)eature-Caps由P-CSCF添加SupportedAllowMax-ForwardViaP-Preferred-Identity缺省不帶，P-CSCF從From獲取PUIRoute初始SIPINVITE中UE不攜帶，話內(nèi)SIP請求，UE攜帶Record-Route轉(zhuǎn)換的RouteRecord-Route初始SIPINVITE中UE不攜帶Min-SESession-ExpiresP-Preferred-ServiceP-Early-MediaAccept-ContactSecurity-Client啟用IPSec時(shí)，UE攜帶Security-Verify啟用IPSec時(shí)，UE攜帶AcceptP-Access-Network-Info由P-CSCF添加，可根據(jù)前述緩存的消息填充SDP中屬性字段說明o行的sessionId、versionIdUE填寫SDP時(shí)，該字段可以縮短長度。o行的ip地址UE填寫SDP時(shí)，該字段可以固定填寫s=-。UE填寫SDP時(shí)，只攜帶一個(gè)c行。UE填寫SDP時(shí)，v行不帶b行，只保留m行下的b行。precondition參數(shù)不考慮precondition，UE不填寫precondition參數(shù)。SDP的a=sendrecvUE填寫SDP時(shí)，不填寫SDP的a=sendrecv。一套簡化的SIP定時(shí)器管理方案，通過動(dòng)態(tài)調(diào)整關(guān)鍵定時(shí)器值，顯著提升VoG方案的核心思想是預(yù)先定義兩套SIP定時(shí)器配置：地面默認(rèn)配置和GEO專其中PANI頭指示RAT類型為GEONB-IoT。UE根據(jù)本地配置或網(wǎng)絡(luò)指也是GEO接入，則其已在注冊時(shí)啟用GEO配置，雙方使用GEO定時(shí)器交互。若MTUE是地面接入，則其服務(wù)IMS網(wǎng)元可根據(jù)收到的主叫RAT類型信息，GEO端的慢響應(yīng)而超時(shí)）。呼叫雙方基于調(diào)整后的長定時(shí)器進(jìn)行信令交互，有在覆蓋范圍廣、資源受限的GEONB-IoTNTN環(huán)境中，保障緊急呼叫的可必須確保UE能獲取其實(shí)際所在國家/地區(qū)的正確緊方案的核心在于網(wǎng)絡(luò)側(cè)根據(jù)UE的實(shí)時(shí)地理位置（國家碼MCC）動(dòng)態(tài)提供并更在初始配置階段，UE在附著請求或跟蹤區(qū)更新請求中，向MME上報(bào)其粗），建立。若UE未正確識別緊急呼叫，P-CSCF也可基于運(yùn)營商策略進(jìn)行檢測。檢測后，P-CSCF可選擇拒絕會(huì)話并要求UE重新發(fā)起，以便UE發(fā)起緊急呼叫流該方案通過基于實(shí)時(shí)地理位置的動(dòng)態(tài)緊急號碼推送機(jī)制，核心解決了GEO緊急呼叫必須盡可能提供主叫方位置信息，這對具體技術(shù)方案包括UE通過NAS安全模式命令程序向MME報(bào)告粗略位置中向IMS核心網(wǎng)報(bào)告。當(dāng)IMS核心網(wǎng)需要驗(yàn)證或獲取額外位置信息時(shí)，可以通的QoS要求，如果之前獲取的粗略位置滿足要求則直接返回，否則與E-SMLC交互進(jìn)行位置信息驗(yàn)證，通過將GNSS信息與粗略位置進(jìn)行比對來驗(yàn)證GNSS測到緊急情況時(shí)需要復(fù)用EPC-NI-LR程序的基本邏輯，但對于NB-IoTGEO接入場景，MME通過NAS安全模式命令程序獲取UE位置而不是向E-SMLC發(fā)EMERGENCY_CALL_RELEASE事件。整體方案可復(fù)用現(xiàn)有的位置服務(wù)框架，通過適配NB-IoTGEO特有的約束條件來實(shí)現(xiàn)緊急服務(wù)的位語音媒體流和IMS信令統(tǒng)一采用NB-IoT（GEO）用戶面承載，通過DRB與S1-U進(jìn)行傳輸，不再依賴控制面數(shù)據(jù)通道IMS語音信令和媒體共用同一個(gè)IPPDN連接，UE在該P(yáng)DN連接建語音媒體承載以基于IP的傳輸為主，結(jié)合頭壓縮技術(shù)在NB-Io基于SIP語音信令呼叫流程的精簡與優(yōu)化可以和消息簡化/壓縮共部署3.2非IMS業(yè)務(wù)的UE-Sat-UE增強(qiáng)），UE-Sat-UE增強(qiáng)，可將GEO衛(wèi)星UE-to-UE本地通信機(jī)制擴(kuò)展至NGSO態(tài)性帶來的5GLAN服務(wù)連續(xù)性挑戰(zhàn)，實(shí)現(xiàn)衛(wèi)星上UPF的本地流量切換而無需組其他成員相同時(shí)繼續(xù)星上本地切換；通過ISL可達(dá)其他成員衛(wèi)星時(shí)經(jīng)N19/N6隧道轉(zhuǎn)發(fā)流量，衛(wèi)星變更過程中支持切換本地交換模式和地面轉(zhuǎn)發(fā)模式。服此外，可以考慮在5GVN組數(shù)據(jù)中新增例如"UE-SAT-UEcommunicationindication"參數(shù)，使SMF能夠基于DNN、S-NSSAI和衛(wèi)星信息明確識別支持UE-SAT-UE通信的5GVN組，并對非衛(wèi)星接入U(xiǎn)E的此類