TWI742619B

TWI742619B - 無線通信系統中請求單播傳送的側鏈路無線電承載配置的方法和設備

Info

Publication number: TWI742619B
Application number: TW109113108A
Authority: TW
Inventors: 潘立德; 郭豊旗
Original assignee: 華碩電腦股份有限公司
Priority date: 2019-05-02
Filing date: 2020-04-17
Publication date: 2021-10-11
Also published as: EP3742832B1; US11589254B2; EP3742832A1; JP2020184752A; US10904787B2; KR20200128354A; CN111885734B; JP6902651B2; TW202044902A; US20200351699A1; ES2934143T3; KR102328223B1; CN111885734A; US20210105653A1

Abstract

從第一用戶設備的角度公開一種方法和設備，以請求與第二用戶設備的單播鏈路的側鏈路無線電承載配置。在一個實施例中，方法包含第一用戶設備從第二用戶設備接收第一消息，其中第一消息包含單播鏈路的第一側鏈路無線電承載配置。方法還包含當第一用戶設備接收到第一消息，或與第一消息相關聯的完成消息成功傳送到第二用戶設備被確認時，第一用戶設備將第二消息傳送到網絡節點以請求單播鏈路的第二側鏈路無線電承載配置。

Description

無線通信系統中請求單播傳送的側鏈路無線電承載配置的方法和設備

本公開大體上涉及無線通訊網路，且更確切地說涉及無線通訊系統中請求單播傳送的側鏈路無線電承載配置的方法和設備。

隨著對將大量數據傳輸到行動通訊裝置以及從行動通訊裝置傳輸大量數據的需求的快速增長，傳統的行動語音通訊網路演變成與互聯網協定（Internet Protocol，IP）數據封包通訊的網路。此類IP數據封包通訊可以為行動通訊裝置的使用者提供IP承載語音、多媒體、多播和點播通訊服務。

示範性網路結構是演進型通用陸地無線電存取網（Evolved Universal Terrestrial Radio Access Network，E-UTRAN）。E-UTRAN系統可提供高數據處理量以便實現上述IP承載語音及多媒體服務。目前，3GPP標準組織正在討論新下一代（例如，5G）無線電技術。因此，目前在提交和考慮對3GPP標準的當前主體的改變，以對3GPP標準進行修訂和定稿。

從第一使用者設備（User Equipment，UE）的角度公開一種方法和設備，以請求與第二UE的單播鏈路的側鏈路無線電承載（Sidelink Radio Bearer，SLRB）配置。在一個實施例中，該方法包含該第一UE從該第二UE接收第一消息，其中該第一消息包含用於該單播鏈路的第一SLRB配置。該方法還包含當該第一UE接收到該第一消息，或與該第一消息相關聯的完成消息成功傳送到該第二UE被確認時，該第一UE將第二消息傳送到網路節點以請求該單播鏈路的第二SLRB配置。

下文描述的示範性無線通訊系統和裝置採用支援廣播服務的無線通訊系統。無線通訊系統經廣泛部署以提供例如語音、數據等各種類型的通訊。這些系統可以基於碼分多址（code division multiple access，CDMA）、時分多址（time division multiple access，TDMA）、正交頻分多址（orthogonal frequency division multiple access，OFDMA）、3GPP長期演進（Long Term Evolution，LTE）無線存取、3GPP長期演進高級（Long Term Evolution Advanced，LTE-A或LTE-Advanced）、3GPP2超行動寬頻（Ultra Mobile Broadband，UMB）、WiMax、3GPP新無線電（New Radio，NR）或一些其它調變技術。

具體地說，下文描述的示範性無線通訊系統裝置可設計成支援一個或多個標準，例如在本文中稱為3GPP的名為“第三代合作夥伴計畫”的聯盟提供的標準，包含： TS 36.213 V15.3.0，“E-UTRA；實體層程序（版本15）”；TS 36.212 V15.2.1，“E-UTRA；實體層；多工和通道解碼（版本15）”；TS 36.211 V15.2.0，“E-UTRA；實體層；實體通道和調變（版本15）”；TS 36.214 V15.1.0，“E-UTRA）；實體層；測量（版本15）”；TS 38.211 V15.4.0（2018-12），“NR；實體通道和調變（版本15）”；TS 38.213 V15.4.0（2018-12），“NR；用於控制的實體層程序（版本15）”；RP-182111，“修正SID：關於NR V2X的研究”，LG Electronics；R1-1810051，“3GPP TSG RAN WG1 #94 v1.0.0的最終報告（瑞典哥德堡，2018年8月20日-24日）；R1-1812101，“3GPP TSG RAN WG1 #94bis v1.0.0的最終報告（中國成都，2018年10月8日-12日）”；R1-1901482，“3GPP TSG RAN WG1 #95 v0.1.0的最終報告（美國斯波坎，2018年11月12日-16日）”；R1-1901483，“3GPP TSG RAN WG1 #AH_1901 v1.0.0的最終報告（臺灣臺北，2019年1月21日-25日）”；3GPP TSG RAN WG1 #96 v0.1.0的草案報告（希臘雅典，2019年2月25日-3月1日）；R1-1901052，“關於側鏈路HARQ程序的考慮”，Samsung；R1-1901683，“用於NR側鏈路的實體層程序”，vivo；R1-1901931，“關於用於NR V2X的實體層程序的論述”，LG Electronics；R1-1901993，“關於NR V2X中的實體層程序的論述”，CATT；R1-1903769，“用於議程項目7.2.4.1.1實體層結構的特寫導語概述#3”，LG Electronics；R1-1903597，“用於議程項目7.2.4.1.2實體層程序的特寫導語概述#2”，LG Electronics；以及3GPP TS 38.331 V15.4.0（2018-12），“NR；無線電資源控制（RRC）協定規範（版本15）”。上文所列的標準和文獻特此明確地以全文引用的方式併入。

第1圖展示根據本發明的一個實施例的多址存取無線通訊系統。存取網絡100（AN）包含多個天線群組，其中一個天線群組包含104和106，另一天線群組包含108和110，且額外天線群組包含112和114。在第1圖中，針對每一天線群組僅展示兩個天線，但是每一天線群組可利用更多或更少天線。存取終端116（AT）與天線112和114通訊，其中天線112和114經由前向鏈路120向存取終端116傳送訊息，並經由反向鏈路118從存取終端116接收訊息。存取終端（AT）122與天線106和108通訊，其中天線106和108經由前向鏈路126向存取終端（AT）122傳送訊息，並經由反向鏈路124從存取終端（AT）122接收訊息。在FDD系統中，通訊鏈路118、120、124和126可使用不同頻率以供通訊。例如，前向鏈路120可使用與反向鏈路118所使用頻率不同的頻率。

每個天線群組和/或其設計成在其中通訊的區域通常被稱作存取網絡的扇區。在實施例中，天線群組各自被設計成與存取網絡100所覆蓋的區域的扇區中的存取終端通訊。

在經由前向鏈路120和126的通訊中，存取網絡100的傳送天線可利用波束成形以便改進不同存取終端116和122的前向鏈路的信噪比。並且，相比於通過單個天線傳送到它的所有存取終端的存取網絡，使用波束成形來傳送到在存取網絡的整個覆蓋範圍中隨機分散的存取終端的該存取網絡對相鄰細胞中的存取終端造成更少的干擾。

存取網絡（access network，AN）可以是用於與終端通訊的固定台或基站，並且也可以被稱作存取點、Node B、基站、增強型基站、演進型Node B（evolved Node B，eNB），或某一其它術語。存取終端（access terminal，AT）還可以被稱作使用者設備（user equipment，UE）、無線通訊裝置、終端、存取終端或某一其它術語。

第2圖是MIMO系統200中的傳送器系統210（也被稱作存取網絡）和接收器系統250（也被稱作存取終端（access terminal，AT）或使用者設備（user equipment，UE））的實施例的簡化方塊圖。在傳送器系統210處，從數據源212將用於數個數據流的業務數據提供到傳送（TX）數據處理器214。

在一個實施例中，通過相應的傳送天線傳送每個數據流。TX數據處理器214基於針對每一數據流而選擇的特定解碼方案來格式化、解碼及交錯該數據流的業務數據以提供經解碼數據。

可使用OFDM技術將每個數據流的經解碼的數據與導頻數據多工。導頻數據通常為以已知方式進行處理的已知數據樣式，且可在接收器系統處使用以估計通道回應。每一數據流的多工導頻和經解碼數據接著基於為該數據流選擇的特定調變方案（例如，BPSK、QPSK、M-PSK或M-QAM）來調變（即，符號映射）以提供調變符號。可以通過由處理器230執行的指令來確定用於每個數據流的數據速率、解碼和調變。

接著將所有數據流的調變符號提供給TX MIMO處理器220，該TX MIMO處理器可進一步處理該調變符號（例如，用於OFDM）。TX MIMO處理器220接著將NT個調變符號流提供給NT個傳送器（TMTR）222a至222t。在某些實施例中，TX MIMO處理器220將波束成形權重應用於數據流的符號及正從其傳送該符號的天線。

每一傳送器222接收和處理相應符號流以提供一個或多個模擬訊號，且進一步調節（例如，放大、濾波和升頻轉換）該類比訊號以提供適於經由MIMO通道傳送的經調變訊號。接著分別從NT個天線224a至224t傳送來自傳送器222a至222t的NT個經調變訊號。

在接收器系統250處，由NR個天線252a至252r接收所傳送的經調變訊號，並且將從每個天線252接收到的訊號提供到相應的接收器（RCVR）254a至254r。每個接收器254調節（例如，濾波、放大和降頻轉換）相應的接收到的訊號，將已調節訊號數位化以提供樣本，且進一步處理該樣本以提供對應的“接收到的”符號流。

RX數據處理器260接著基於特定接收器處理技術從NR個接收器254接收並處理NR個接收到的符號流以提供NT個“檢測到的”符號流。RX數據處理器260接著對每一檢測到的符號流進行解調、解交錯和解碼以恢復數據流的業務數據。由RX數據處理器260進行的處理與由TX MIMO處理器220和TX數據處理器214在傳送器系統210處所執行的處理互補。

處理器270週期性地確定要使用哪個預解碼矩陣（下文論述）。處理器270制定包括矩陣索引部分和秩值部分的反向鏈路消息。

反向鏈路消息可以包括與通訊鏈路和/或接收到的數據流有關的各種類型的訊息。反向鏈路消息接著由TX數據處理器238（其還接收來自數據源236的數個數據流的業務數據）處理，由調變器280調變，由傳送器254a至254r調節，且被傳送回到傳送器系統210。

在傳送器系統210處，來自接收器系統250的經調變訊號通過天線224接收、通過接收器222調節、通過解調器240解調，並通過RX數據處理器242處理，以提取通過接收器系統250傳送的反向鏈路消息。接著，處理器230確定使用哪一預解碼矩陣以確定波束成形權重，然後處理所提取的消息。

轉而參看第3圖，此圖展示了根據本發明的一個實施例的通訊裝置的替代簡化功能方塊圖。如第3圖中所展示，可以利用無線通訊系統中的通訊裝置300以用於實現第1圖中的UE（或AT）116和122或第1圖中的基站（或AN）100，並且無線通訊系統優選地是LTE或NR系統。通訊裝置300可包含輸入裝置302、輸出裝置304、控制電路306、中央處理單元（CPU）308、記憶體310、程式碼312以及收發器314。控制電路306經由CPU 308執行記憶體310中的程式碼312，由此控制通訊裝置300的操作。通訊裝置300可接收由使用者經由輸入裝置302（例如，鍵盤或小鍵盤）輸入的訊號，且可經由輸出裝置304（例如，顯示器或揚聲器）輸出圖像和聲音。收發器314用於接收和傳送無線訊號，從而將所接收的訊號遞送到控制電路306且以無線地方式輸出由控制電路306生成的訊號。也可以利用無線通訊系統中的通訊裝置300來實現第1圖中的AN 100。

第4圖是根據本發明的一個實施例的第3圖中展示的程式碼312的簡化方塊圖。在此實施例中，程式碼312包含應用層400、層3部分402和層2部分404，且耦合到層1部分406。層3部分402通常執行無線電資源控制。層2部分404通常執行鏈路控制。層1部分406通常執行實體連接。

如在3GPP RAN2#104主席紀要中所論述，3GPP RAN2#104會議關於NR eV2X側鏈路通訊達成以下協定：關於單播的協定 1: 對於針對SL單播需要經由側鏈路在UE之間交換的AS級訊息，RAN2可以將以下視為基線，且將檢查是否可以協定AS級訊息以及RAN2、SA2和RAN1中的某一進程之後的細節： - UE ID、UE能力、無線電/承載配置、PHY訊息/配置（例如，HARQ、CSI）、資源訊息/配置和QoS訊息 2: 可以針對RRC配置在gNB與UE之間交換用於SL單播的AS級訊息。RAN2假設UE可以向網路提供QoS相關訊息，且將檢查是否可以協定AS級訊息以及RAN2、SA2和RAN1中的某一進程之後的細節。 3: 針對SL單播經由側鏈路在UE之間經由RRC信令（例如，PC5-RRC）交換AS級訊息。除STCH（SL業務通道）之外還將引入新邏輯通道（SCCH：SL控制通道）。SCCH攜載PC5-RRC消息。 4: RAN2將考慮SI階段期間的兩個選項。需要關於每一選項的定義、程序和訊息的進一步論述。 - 選項1：還需要透過PC5-RRC進行AS層連結建立程序。 - 選項2：上層連結建立程序已足夠。 5: RAN2將研究一種基於RRM或RLM的AS級鏈路管理。RAN2將不考慮一種基於PC5-RRC級保活（keep alive）消息的管理。需要關於可能的詳細選項的進一步論述。

3GPP TR 23.786介紹了用於eV2X通訊的以下解決方案： 6.11 解決方案#11：透過PC5參考點進行的eV2X通訊的單播或多播解決方案 6.11.1 功能描述此解決方案解決關於eV2X群組通訊的支援的關鍵問題#1、關於透過PC5的單播/多播通訊的支援的關鍵問題#9，以及關於針對eV2X的PC5 QoS框架增強的支援的關鍵問題#4，聚焦於以下方面： - 用於單播通訊的標識符，例如L2 ID； - 用於支援單播/多播通訊的信令協議； - QoS支援和AS層配置； - 安全關聯； - 用於鏈路建立和維護的程序。 6.11.2 解決方案描述 6.11.2.1 用於單播通訊的標識符 6.11.2.1.1 與用於廣播的L2 ID位址空間分開的用於單播和多播的L2 ID位址空間用於單播/多播通訊的必要標識符中的一個為L2 ID。截至TS 23.303[8]中的ProSe設計，用於一對一通訊和一對多通訊的目的地L2 ID位址空間與AS層機制，即MAC層版本號分開。這樣做是為了避免所使用位址的衝突可能引起對一對一通訊的損害。以類似方式，V2X單播還應使用與用於廣播和多播的L2 ID分開的L2 ID。此分開適用於目的地L2 ID和源L2 ID兩者。對於具有廣播和單播/多播業務兩者的UE，不同L2 ID應與對應的格式一起使用。源L2 ID將由對等UE用作單播通訊中的目的地L2 ID。以下條款中描述用於單播/多播的相關L2 ID管理的細節。 UE可以針對不同的單播一對一通訊鏈路使用不同源L2 ID，例如當不同單播鏈路與不同上層標識符相關聯時。 6.11.2.1.2 決定將目的地L2 ID用於單播/多播通訊 6.11.2.1.2.1 選項A 在TS 23.285[5]中，由UE基於PSID/ITS-AID到L2 ID之間的所配置映射來決定目的地L2 ID。此適於廣播業務，但不適用於單播或多播業務。在單播或多播中，將不會基於PSID/ITS-AID決定目的地L2 ID。應允許V2X UE具有針對特定服務（PSID/ITS-AID）同時支援的複數個單播連結或多播群組。因此，在此情況下，目的地L2 ID訊息應來自上層。這意味著V2X層和上層之間的介面需要增強以允許此類訊息連同資料封包一起傳遞下去。預期實際V2X應用不理解L2 ID的概念，因為該應用可以針對跨技術或平臺構建。因此，UE內的某一中介軟體層必須將例如網站ID等應用層使用的標識符轉譯為V2X L2 ID。這意味著此中介軟體層需要維持應用層目的地標識符與L2 ID的映射。因為此中介軟體層在SA2的範圍外，所以在說明書中其通常可以標註為“上層”，且應記載此“上層”維持映射並提供用於單播或多播通訊的L2 ID的假設。 6.11.2.1.2.2 選項B 上述解決方案的替代方案是V2X層管理此單播鏈路/多播群組到L2 ID映射。在這種情況下，可以在建立時向單播鏈路/多播群組分配流標識符。例如L2 ID、傳送設定、QoS參數等對應的連結設定檔訊息可以與其相關聯。在這種情況下，上層僅需要使用流標識符來指示目的地並將其與資料封包一起傳遞下去。V2X層將應用包含L2 ID的相關聯設定檔訊息用於傳送。這將允許再使用例如類似於QoS流的Uu鏈路處理機制的Uu鏈路處理機制，且更可擴展。再次，例如網站ID等應用層標識符到此流標識符的轉譯必須由此中介軟體層，即“上層”進行。 6.11.2.2 用於支援單播/多播通訊的信令協議對於單播或多播通訊，需要在所涉及的UE之間交換一些控制消息以便建立鏈路或群組。因此，需要某一信令協定。在TS 23.303 [8]中定義的ProSe一對一通訊中，介紹了透過PDCP層運行的PC5信令協議（條款5.1.1.5.2）。儘管其針對ProSe使用定義，但該消息可以擴展以便用於V2X通訊。詳細的協定設計需要基於實際單播操作程序來檢視。另一替代方法是透過PC5運行RRC。由於PC5信令協議無論如何都在PDCP上使用，因此RRC協定可以用於替代PC5信令協議。儘管PC5操作並非需要所有RRC特徵，但可以擴展和使用那些所選V2X相關RRC消息，例如SidelinkUEInformation等。優點是用於Uu和PC5的控制信令協議的潛在統一。因此，在這種解決方案中，引入用於單播/多播通訊管理的透過PC5的信令協議。6.11.2.3 QoS 支援和 AS 層配置 合乎需要的是，也可以透過單播和多播通訊支援QoS。在TS 23.285[5]中，用於V2X通訊的QoS模型是基於每封包模型，例如PPPP和PPPR。在單播或多播通訊的情況下，應論述是否也應支援與Uu連結類似的連線導向的QoS模型。還如關鍵問題#4“用於eV2X的PC5 QoS架構增強的支援”中論述，預期需要不止現有PPPP和PPPR。特定地針對單播或多播，歸因於所涉及的鏈路或群組，透過一對對等體之間的相同單播鏈路發送的大多數封包應具有相同QoS特性。這更接近Uu連結模型，而非正常基於廣播的業務。因此，此處可以再使用QoS管理概念的Uu類型。此允許用於Uu和PC5的通用模型。另外，可以存在可以為任選或非與舊版相容的不同AS層特徵。因此，當設置單播鏈路時，此配置還可以連同QoS範本或作為QoS範本的一部分而協商和配置。註：使用解決方案#19（條款6.19）中描述的用於單播的QoS模型。 6.11.2.4 安全關聯單播或多播通訊可能在鏈路層處也需要保護。ProSe一對一通訊支援安全L2鏈路建立，如TS 33.303 [11]中所定義。然而，在V2X通訊上下文內，每一UE具有用於安全保護的對應證書。因此，可能需要增強或調整現有L2安全鏈路建立協定以便支援此類安全關聯的使用。應由SA3分析並決定準確的安全處理。當可用時，SA2設計需要與那些決策對準。 6.11.2.5 用於鏈路建立和維護的程序 TS 23.303[8]已定義用於安全L2鏈路透過PC5的建立和維護的程序，如在條款5.4.5中。受制于上文關於信令協議選擇、安全處理等的決策，這些程序可以得到增強並適用於V2X使用。但需要用於鏈路/群組處理的V2X的一些額外考慮因素。對於V2X通訊，並非全部UE將支援或使用單播通訊。另外，並非全部服務可以透過相同通道或RAT運行（例如LTE V2X相對於NR V2X）。在V2X的情況下，不存在類似於ProSe的發現通道（即，PC5-D）的發現通道，且不存在關於來自網路的配置，例如公共安全使用的配置的假設。因此，為了支援鏈路建立，需要服務宣告以便告知對等方UE的存在和該UE進行單播通訊的能力，例如操作的通道或所支援的服務等。應使此服務宣告可由對使用服務感興趣的所有UE訪問。舉例來說，此宣告可以被配置成透過專門的通道發送，類似於處理WAVE服務廣告（WAVE Service Advertisement，WSA）的方式，或在來自支援UE的定期消息上捎帶。註1：服務宣告由上層處理且在SA2的範圍外。對於層2鏈路維護，需要保活功能性來檢測何時UE不在直接通訊範圍內，使得其可以繼續進行隱式層2鏈路釋放。註2：由級3來確定如何支援保活功能性。 6.11.3 程序 6.11.3.1 層2鏈路透過PC5的建立 TS 23.303 [8]條款5.4.5.2中定義的層2鏈路建立程序可以重新用於eV2X單播鏈路建立，進行以下修改： - 取決於RAN WG的決策，消息可以被轉換為RRC信令消息而不是PC5信令消息。 - “面向UE的層2鏈路建立”如下操作，且圖6.11.3.1-1展示程序： - 直接通訊請求消息可以由UE-1以廣播機制發送，即，發送到與應用相關聯的廣播地址，而不是UE-2的L2 ID。UE-2的上部標識符包含在直接通訊請求消息中，以允許UE-2決定是否對請求作出回應。此消息的源L2 ID應是UE-1的單播L2 ID。 - 應使用UE-2可以理解的默認AS層設置，例如廣播設置來傳送直接通訊請求消息。 - UE-2在向UE-1的後續信令中使用接收到的直接通訊請求消息的源L2 ID作為目的地L2 ID，並使用其自身的單播L2 ID作為源L2 ID。UE-1獲得UE-2的L2 ID，以用於將來的通訊、信令和資料業務。 [標題為“面向UE的層2鏈路建立程序”的3GPP TR 23.786 V1.0.0的圖6.11.3.1-1重製為第5圖] - “面向V2X服務的層2鏈路建立”與“面向UE的層2鏈路建立”相同地操作且具有以下差異，且圖6.11.3.1-2示出該程序： - 關於請求L2鏈路建立的V2X服務的訊息，即，關於宣告的V2X服務的訊息包含在直接通訊請求消息中以允許其它UE決定是否對請求作出回應。 - 對使用由直接通訊請求消息宣告的V2X服務感興趣的UE可以對該請求作出回應（圖6.11.3.1-2中的UE-2和UE-4）。 - 在如上文所描述與其它UE建立層2鏈路之後，新UE可以進入UE-1的近程，即UE-1的直接通訊範圍。在此情況下，UE-1可以起始面向V2X服務的層2鏈路建立程序，因為其從由UE發送的應用層消息感知到新UE。或新UE可以起始面向V2X服務的層2鏈路建立程序。因此，UE-1不必保持週期性地發送直接通訊請求消息來宣告V2X服務其想要與其它UE建立單播L2鏈路。 [標題為“面向V2X服務的層2鏈路建立程序”的3GPP TR 23.786 V1.0.0的圖6.11.3.1-2重製為第6圖] 層2鏈路支援非IP業務。將不執行IP位址協商和分配程序。 6.11.3.2 用於鏈路建立的信令消息的內容 TS 24.334 [13]中定義的直接通訊請求消息中攜載的訊息需要至少以下更新： - 對於“面向UE的層2鏈路建立”， - 除起始UE的ID （UE-1的上層ID）外，使用者訊息還需要包含目標UE的ID （UE-2的上層ID）。註：級3可以決定這些ID可以攜載於相同IE還是單獨IE中，例如網站ID/車輛溫度ID僅需要為4個八位元位元組。 - 對於“面向V2X服務的層2鏈路建立”， - 宣告的V2X服務訊息需要包含關於請求L2鏈路建立的V2X服務的訊息，例如V2X應用的PSID或ITS-AID。感測器共用等可以是針對V2X服務的情況。 - 對於ProSe指定為必選的IP位址配置應允許將不使用IP，使得接收UE（例如，UE-2）將不針對此特定鏈路起始任何IP配置程序的指示。 - 專用於安全性的IE需要由SA3檢查，因為用於eV2X的安全機制可以不同且需要不同IE。 - 關於鏈路的額外配置訊息，例如當使用RRC消息時，可以存在AS層配置。 6.11.3.3 用於單播通訊的隱私保護的鏈路標識符更新程序 [標題為“層2鏈路標識符更新程序”的3GPP TR 23.786 V1.0.0的圖6.11.3.3-1重製為第7圖] 此程序用於在單播通訊中更新用於此鏈路的標識符的即將變化的對等體。由於隱私要求，在eV2X使用中，UE應經常改變其標識符，以免被協力廠商追蹤。當發生標識符改變時，所有層，即從應用層ID到L2 ID上的所有標識符都需要改變。標識符改變發生之前需要此信令，以防止服務中斷。 1. UE-1例如歸因於上層標識符改變或計時器而決定標識符的改變，且包含新標識符（包含新上層標識符、新IP位址/首碼（如果適用）、新L2 ID）以在鏈路標識符更新請求消息中使用，且在其改變標識符之前發送到UE-2。將要使用的新標識符應加密以保護隱私。註1：計時器基於每源L2 ID運行。 2. UE-2以鏈路標識符更新回應訊息進行回應。在接收消息後，UE-1和UE-2可以開始將該新標識符用於資料業務。UE-1應在其舊L2 ID上接收業務直至其從UE-2接收到鏈路Id更新回應。註2：如果來自UE-1的複數個鏈路使用相同上層標識符或L2 ID，則UE-1需要在每個鏈路上執行更新程序，並且對於每個鏈路，需要在其舊L2 ID上保持接收該特定鏈路的業務，直到UE-1接收到鏈路ID更新回應。 6.11.3.4 用於層2鏈路的安全方面因為eV2X應用具有相關聯的安全證書，所以單播鏈路可以再使用那些證書以得出安全關聯來保護單播鏈路的信令或資料。 6.11.4 對現有實體和介面的影響編者註：對現有節點或功能性的影響將增加。 6.11.5 進一步研究的話題無。 6.11.6 結論條款6.11.1到6.11.4中記載的解決方案解決了關鍵問題#9“用於透過PC5的感測器共用的單播/多播的支援”的所有方面，且應轉向規範性階段。將基於來自其它工作團隊的回饋進一步更新以下方面： - 用於單播鏈路建立和管理的信令消息定義，例如RRC信令是否以及如何用於單播鏈路； - 基於RAN決策針對廣播、組播和單播選擇每封包QoS模型或基於載送的QoS模型； - 當使用網路排程模式時關於所使用的服務的到基站的訊號； - 用於透過PC5的單播通訊的潛在安全相關程序更新。註：應用層可以針對不同應用，例如，佇列應用使用單播或組播通訊機制。 […] 6.19 解決方案#19：對透過PC5介面進行的eV2X通訊的QoS支援 6.19.1 功能描述 6.19.1.1 一般描述此解決方案解決了關鍵問題#4（條款5.4）對eV2X的PC5 QoS架構增強的支援。用於eV2X的QoS要求不同於EPS V2X的QoS要求，並且考慮TS 23.285[5]中的先前定義的PPPP/PPPR不滿足需要。具體來說，對於eV2X服務存在更多將要考慮的QoS參數。此解決方案提出將5QI用於透過PC5介面進行的eV2X通訊。這允許用於透過不同鏈路的eV2X服務的通用QoS模型。 6.19.1.2 解決方案描述在TS 22.186[4]中捕獲新的服務要求。透過以下參數指定新性能KPI： - 有效負載（位元組）； - 傳送速率（消息/秒）； - 最大端對端等待時間（ms）； - 可靠性（%）； - 資料速率（Mbps）； - 所需最小通訊範圍（公尺）。應注意，相同組的服務要求適用於基於PC5的V2X通訊和基於Uu的V2X通訊兩者。如解決方案#2（條款6.2）中所分析，這些QoS特性可以用TS 23.501[7]中定義的5QI很好地表示。因此，可能具有用於PC5和Uu的通用QoS模型，即，還將5QI用於透過PC5進行的V2X通訊，使得應用層可以具有指示QoS要求的一致方式，而無論使用的鏈路如何。這並不防止AS層實施透過PC5和Uu的不同機制以實現QoS要求。考慮具有5GS V2X功能的UE，存在三個不同類型的業務：廣播、多播和單播。 UE-PC5-AMBR應用於所有類型的業務，並且用於RAN以限制資源管理中的UE PC5傳送。對於單播類型的業務，顯然可以利用與Uu的QoS模型相同的QoS模型，即單播鏈路中的每一個可以視為載送，且QoS流可以與其相關聯。5QI中定義的所有QoS特性和資料速率的額外參數可以適用。另外，最小所需通訊範圍可以視為特定針對PC5使用的額外參數。對於廣播業務，不存在載送概念。因此，消息中的每一個可以根據應用要求具有不同特性。接著應透過與PPPP/PPPR類似的方式使用5QI，即，將用封包中的每一個標記5QI。5QI能夠表示PC5廣播操作所需的所有特性，例如等待時間、優先順序、可靠性等。可以針對PC5使用定義V2X廣播特定5QI（即VQI）的群組。註1：甚至對於相同V2X服務，用於PC5的5QI可以不同於用於Uu的5QI，例如用於PC5的PDB可以長於用於Uu的PDB，因為它是直接鏈路。用於PC5的5QI稱為VQI以便於辨別。註2：例如PPPP和PPPR的EPS V2X QoS參數與例如類似於TS 23.501[7]中定義的非GBR 5QI的新VQI之間的映射將在規範性階段定義以用於廣播操作。註3：工作假設為，NR PC5設計支援V2X 5QI的使用。註4：AS層可以透過考慮例如由VQI指示的所有其優先順序來處理單播、組播和廣播業務。 6.19.1.3 用於PC5廣播使用的V2X 5QI（VQI）值用於V2X使用的一組新VQI將在規範性階段中定義，反映TS 22.186[4]中記錄的服務要求。註1：工作假設此版本中不支援非標準化VQI。註2：是否使用每封包或每QoS流QoS模型取決於RAN決策。 6.19.2 程序編者註：本條款描述使用新QoS模型用於PC5通訊的程序。這也取決於RAN開發。 6.19.2.1 對透過PC5介面進行的單播通訊的QoS支援 6.19.2.1.0 一般為了實現對透過PC5介面進行的eV2X一對一通訊的QoS支援，需要支援以下程序。編者註：以下程序可以取決於PC5 QoS模型上的進程而進一步更新。 6.19.2.1.1 QoS參數到UE和NG-RAN的提供使用針對關鍵問題#5定義的解決方案將PC5 QoS參數和PC5 QoS規則提供到UE，作為業務授權參數的一部分。PC5 QoS規則用於將V2X服務（例如，V2X應用的PSID或ITS-AID）映射到PC5 QoS流。將由PCF從UDR檢索的PC5 QoS參數經由AMF提供到NG-RAN。AMF存儲此訊息作為UE上下文的一部分。對於後續程序（例如，服務請求、交遞)，經由N2提供PC5 QoS參數將遵循按照條款6.6.2的描述。註1：UE-PC5-AMBR由UDM提供，且細節將遵循按照解決方案#6的描述。提供到UE和NG-RAN的PC5 QoS參數可以由包含在UE提供的NAS消息中的UE策略容器觸發。PCF在需要時向AMF發送用於NG-RAN的更新的PC5 QoS參數。註2：由NG-RAN使用的詳細PC5 QoS參數將在規範性工作階段期間識別。註3：NG-RAN透過用於網路排程的資源配置模式的靜態參數配置以支援PC5 QoS。 6.19.2.1.2 UE之間的QoS參數協商在一對一通訊程序建立時協商PC5 QoS參數，因此TS 23.303[8]中定義的一對一通訊建立程序得以增強以支援兩個UE之間的PC5 QoS參數協商。在PC5 QoS參數協商程序之後，相同QoS在兩個方向中使用。 [標題為“透過PC5建立安全層2鏈路”的3GPP TR 23.786 V1.0.0的圖6.19.2.1.2-1重製為第8圖] 參與一對一通訊的UE在鏈路建立程序期間協商PC5 QoS參數。 1. UE-1向UE-2發送直接通訊請求消息，以觸發相互認證。此消息包含所請求的PC5 QoS參數。 2. UE-2起始相互認證的程序。UE-2包含回應訊息中接受的PC5 QoS參數。註：此程序與解決方案#11（條款6.11）對準。 6.19.2.1.3 eV2X通訊的QoS處理當PC5單播用於eV2X消息的傳送時，針對網路排程的操作模式和UE自主資源選擇模式兩者應用以下原理： - 條款6.19.1.2中定義的PC5 QoS參數適用於透過PC5進行的eV2X通訊。 - 在使用條款6.19.2.1.2中描述的程序建立的PC5 QoS流上發送eV2X消息。 - 應用層eV2X消息到PC5 QoS參數的映射是基於PC5 QoS規則的。當使用網路排程的操作模式時，以下額外原理適用： - UE向gNB提供PC5 QoS參數訊息以進行資源請求。 - 當gNB從UE接收針對PC5資源的請求時，gNB可以基於從AMF接收的PC5 QoS參數授權所請求的PC5 QoS參數。 - gNB可以將PC5 QoS參數訊息用於PC5 QoS處理。當使用自主資源選擇模式時，以下附加原理適用： - UE可以基於條款6.19.2.1.1中描述的所提供訊息而將PC5 QoS參數用於PC5 QoS處理。 6.19.2.2 對透過PC5介面進行的廣播通訊的QoS支援當PC5廣播用於eV2X消息的傳送時，針對網路排程的操作模式和UE自主資源選擇模式兩者遵循以下原理： - 條款6.19.1.2中定義的PC5 QoS參數（例如，VQI）適用於透過PC5進行的eV2X通訊。 - 應用層在將每一eV2X消息傳遞到V2X層以供傳送時設定每一eV2X消息的PC5 QoS參數。當使用網路排程的操作模式時，以下額外原理適用： - UE將反映PC5 QoS參數的PC5 QoS訊息提供到gNB以用於資源請求。 - gNB可以將反映PC5 QoS參數的PC5 QoS訊息用於QoS處理。當使用自主資源選擇模式時，以下附加原理適用： - UE可以將PC5 QoS參數用於PC5 QoS處理。註：用於廣播的每封包QoS模型或基於載送的QoS模型的選擇基於RAN決策。 6.19.2.3 對透過PC5介面進行的群組通訊的QoS支援條款6.21.2（解決方案#21）中描述關於對透過PC5介面進行的群組通訊的QoS支援的程序。 6.19.3 對現有實體和介面的影響以下是對UE和其它NF的影響： - UE需要支援用於PC5通訊的新QoS模型。 - AMF向NG-RAN提供在關聯用於不同程序的N2消息時從PCF提取的用於PC5通訊的QoS參數。 - NG-RAN從AMF接收用於PC5通訊的QoS參數，且針對網路排程模式強制執行QoS參數。 - UDR存儲用於PC5通訊的QoS參數。編者註：PPPP、PPPR到新VQI的映射對於廣播業務是否將是必需的，有待進一步研究。 6.19.4 進一步研究的話題編者註：此條款描述用於進一步研究的話題。 6.19.5 結論條款6.19.1到6.19.3中捕獲的解決方案應轉向規範性階段。

3GPP R2-1900370包含以下論述：在一些文稿[11][12][13]中，指出可能需要向接收器UE通知與在傳送器UE側配置的SLRB對應的一些接收器側相關的參數，以便接收器與傳送器對準並且正確地接收從對應SLRB發送的資料。如果此類接收器側相關的SLRB配置是可配置的[13]，則此類接收器側相關的SLRB配置可以包含序號空間和RLC模式，並且原因很容易理解：如果這些參數是可配置的，則當UE接收對應於LCID的資料時，必須由傳送器在對應SL LCH（以及對應SLRB）上向UE通知這些參數的特定值設定，以便正確地處理資料的接收。然而，還有一些其它合理的觀點表明，類似於DL中的UE接收，SL中的接收器處可能不需要QoS強制操作[11]，或者將傳送器對接收器側SLRB配置的此種強制視為一些形式的優化[12] 因此，在下文中，值得討論的是，是否需要由NR SL中的傳送器UE向接收器UE通知此接收器側相關的SLRB配置。而且，在LTE SL中，在TS 36.331[17,9.1.1.6]）中的STCH配置中指定這些接收器側SLRB配置，使得該配置不需要由傳送器通知。

問題5：傳送器UE需要向接收器UE通知NR SL中的任何接收器側相關的SLRB配置（以便在這些配置上對準傳送器和接收器）嗎？如果是，則該接收器側相關的SLRB配置是什麼？ a) 是，需要通知用於接收SLRB的SN長度（如果可配置）。 b) 是，需要通知用於SLRB的RLC模式（如果可配置）。 c) 否。不需要由NR SL中的傳送器通知的此接收器側SLRB配置；該接收器側SLRB配置在規範中指定為LTE SL中的配置。 d) 其它。如果選定，則請闡明其它選項的內容。 e) 是，需要向接收器UE通知與在傳送器UE處建立的每個SLRB/SL LCH相關聯的PC5 QoS範本。 f) 是，需要通知SLRB特定的PHY配置（例如，HARQ/SFCI配置） g) 是，由傳送器UE配置的接收器側SLRB配置（例如，t-重新排序、t-重新組裝等）

3GPP R2-1900370中的附件如下描述用於NW配置/預配置SLRB的若干候選選項：附件：用於NW配置/預配置SLRB的候選選項根據LTE SL的經驗，具有不同RRC狀態/資源配置模式的UE可以取決於信令的不同方式以及用於其SL（預）配置（即，專用信令、系統訊息和預配置）的程序。因此，下文給出具有不同信令流的選項。 ● 選項1 [標題為“基於PC5 QoS 範本的UE特定的配置”的3GPP R2-1900370的圖A-1重製為第9圖] 由於SA2推斷出限定VQI來表示TR 23.786中的每封包PC5 QoS參數並且指示每個V2X消息（每當可適用時）的VQI由應用層[1]設定，因此此選項基於此結論並且進一步假設在每個V2X封包上標記的PC5 PC5參數（例如，VQI等(此處，圖中的特定PC5 QoS參數包含VQI以及由Q2標識的其它可能的QoS參數，因此，置於此處的“等”可以稍後根據Q2結論更新（如果最終支援選項本身）。這也適用於下文的選項3和4)），即PC5 QoS範本（類似於“Uu”，此處的術語“PC5 QoS範本”表示一組PC5 QoS參數，即，VQI以及來自Q2的其它可能的QoS參數）也被提交給AS（類似於傳統PPPP/PPPR），如在以上步驟2中。在步驟3中，UE可以向gNB/ng-eNB報告封包的PC5 QoS範本，並且請求與所報告的這些PC5 QoS範本相關聯的SLRB的配置。作為回應，gNB/ng-eNB可以用訊號通知與所報告的PC5 QoS範本相關聯的SLRB的配置；這些SLRB配置可包含SLRB ID、PC5 QoS範本到SLRB映射、SDAP/PDCP/RLC/LCH配置等。在步驟5中，AS中的UE根據gNB/nb-eNB配置建立與封包的QoS範本相關聯的SLRB，並且將包映射到所建立的SLRB。然後，發生SL傳送。由於SA2在TR 23.786[1]中假設“此版本中不支援非標準化VQI”，因此很有可能類似於NR Uu中使用的5QI，每個VQI的PC5 QoS參數也在規範中標準化。而且，如果VQI本身被視為不足以反映Q2中的所有PC5 QoS參數，則其它所需QoS參數將與VQI一起使用以形成PC5 QoS範本並且也被報告給RAN。因此，此選項的特徵在於，使UE能夠將RAN中的可用封包的QoS參數直接“告知”gNB/ng-eNB，因此不再需要依賴於CN來瞭解如在Uu中的UE業務的QoS範本。適用性：在此選項中，gNB/ng-eNB根據UE所報告的實際可用封包的PC5 QoS參數來配置SLRB，使得SLRB以UE特定方式工作並且應用於RRC_CONNECTED UE。 ● 選項2 [標題為“基於PC5 QoS流的UE特定的配置”的3GPP R2-1900370的圖A-2重製為第10圖] 如圖A-2中所示的選項2將模仿NR Uu中基於QoS流的機制，因為根據TR 23.786[1]中的解決方案#19，還至少針對QoS支援SL單播提出SA2，以使用如下基於PC5 QoS流的機制[1]：

6.19.2.1.1到UE和NG-RAN的QoS參數提供使用針對關鍵問題#5定義的解決方案將PC5 QoS參數和PC5 QoS規則提供到UE，作為業務授權參數的一部分。PC5 QoS規則用於將V2X服務（例如，V2X應用的PSID或ITS-AID）映射到PC5 QoS流。將PC5 QoS參數作為一部分提供給NG-RAN。經由AMF將由PCF從UDR檢索到的PC5 QoS參數提供給NG-RAN。AMF將此訊息存儲為UE上下文的一部分。對於後續程序（例如，服務請求、交遞），PC5 QoS參數經由N2的提供將根據條款6.6.2遵循規範。

具體來說，在步驟0中，如以上SA2結論，透過業務授權和提供過程將每個PC5 QoS流的PC5 QoS參數和PC5 QoS規則預先提供給UE；類似地，還透過預先提供的方式將每個QoS流的PC5 QoS範本提供給eNB/ng-eNB。隨後，當封包到達時，UE可以首先基於在步驟0中配置的PC5 QoS規則得出相關聯PC5 QoS流的標識符，並且隨後在步驟3中將這些PC5 QFI報告給gNB/ng-eNB。在gNB/ng-eNB側處，UE可以基於步驟0中從5GC的提供得出這些所報告PC5 QFI的QoS範本，因此可以用訊號通知與所報告PC5 QFI UE相關聯的SLRB的配置。在步驟5中，AS中的UE根據gNB/ng-eNB配置建立與封包的PC5 QFI相關聯的SLRB，並且將可用封包映射到所建立SLRB。與選項1的最大差異在於，在如在Uu中僅使用QFI的情況下，每個QoS流的特定QoS參數在UE/RAN的AS中可能不直接可見，因此gNB/ng-eNB仍需要取決於來自CN的配置來知曉如在Uu中的特定QoS範本（儘管以預先提供的方式提供QoS範本）。適用性：類似於選項1，此選項僅適用於RRC_CONNECTED UE。 ● 選項3 [標題為“基於PC5 QoS範本的單元特定配置（例如，在V2X特定的SIB中）”的3GPP R2-1900370的圖A-3重製為第11圖] 當人們也想要將NW配置的SLRB應用于RRC_IDLE/RRC_INACTIVE UE時，應用選項3。具體來說，在此選項中，gNB/ng-eNB使用V2X特定的SIB來廣播與每個可能PC5 QoS範本相關聯的SLRB配置。隨後，當具有特定PC5 QoS範本的封包如在步驟1和2中到達時，UE隨後根據SIB中廣播的細胞特定配置建立對應於這些QoS範本的SLRB，並且將封包映射到所建立的SLRB。適用性：此選項僅將UE特定的SLRB配置轉換成細胞特定的配置。儘管其主要設計用於RRC_IDLE/RRC_INACTIVE UE，但是在技術上也可用於RRC_CONNECTED UE。

3GPP TS 36.300如下引入側鏈路無線電承載與側鏈路邏輯通道之間的映射： 6 層2 層2分成以下子層：媒體存取控制（Medium Access Control，MAC）、無線鏈路控制（Radio Link Control，RLC）和封包資料彙聚協定（Packet Data Convergence Protocol，PDCP）。此子條款在服務和功能方面給出層2子層的高級描述。以下三個圖描繪了下行鏈路、上行鏈路和側鏈路的PDCP/RLC/MAC架構，其中： - 對等通訊的服務存取點（Service Access Point，SAP）以子層之間的介面處的圓圈標記。實體層與MAC子層之間的SAP提供傳輸通道。MAC子層與RLC子層之間的SAP提供邏輯通道。 - 相同傳輸通道（即，傳輸塊）上的若干邏輯通道（即，無線電承載）的多工透過MAC子層執行； - 在上行鏈路和下行鏈路兩者中，當都未配置CA和DC時，在不存在空間多工的情況下，每TTI僅生成一個傳輸塊； - 在側鏈路中，每TTI僅生成一個傳輸塊。 […] [標題為“側鏈路的層2結構”的3GPP TS 36.300 V15.3.0的圖6-3重製為第12圖]

3GPP TS 36.331陳述： 5.10.2 側鏈路UE訊息 5.10.2.1 一般 [標題為“側鏈路UE訊息”的3GPP 36.331 V15.3.0的圖5.10.2-1重製為第13圖] 此程序的目標是向E-UTRAN通知UE對接收側鏈路通訊或發現、接收V2X側鏈路通訊感興趣或不再感興趣，以及請求側鏈路通訊或發現通知或V2X側鏈路通訊或側鏈路發現間隙的傳送資源的指派或發佈；報告與來自異頻/PLMN細胞的系統訊息的側鏈路發現有關的參數；以及報告由UE用於V2X側鏈路通訊的同步參考。 5.10.2.2 發起能夠進行RRC_CONNECTED中的側鏈路通訊或V2X側鏈路通訊或側鏈路發現的UE可以發起程序以指示在若干種情況下，UE（感興趣）接收側鏈路通訊或V2X側鏈路通訊或側鏈路發現，該情況包含在成功建立連結後、在發生興趣改變後、在改變成廣播包含sl-V2X-ConfigCommon的SystemInformationBlockType18或SystemInformationBlockType19或SystemInformationBlockType21的PCell後。能夠進行側鏈路通訊或V2X側鏈路通訊或側鏈路發現的UE可以發起程序以請求指派用於相關側鏈路通訊傳送或發現通知或V2X側鏈路通訊傳送的專用資源，或請求用於側鏈路發現傳送或側鏈路發現接收的側鏈路發現間隙，並且能夠進行異頻/PLMN側鏈路發現參數報告的UE可以發起程序以報告與來自異頻/PLMN細胞的系統訊息的側鏈路發現有關的參數。註1：儘管包含sl-V2X-ConfigCommon的SystemInformationBlockType18/ SystemInformationBlockType19/SystemInformationBlockType21或SystemInformationBlockType26不包含用於傳送的資源（在正常條件下），但是被配置成傳送側鏈路通訊/V2X側鏈路通訊/側鏈路發現通知的RRC_IDLE中的UE根據5.3.3.1a發起連結建立。在發起程序後，UE將： […] 1> 如果包含sl-V2X-ConfigCommon的SystemInformationBlockType21由PCell廣播： 2> 確保針對PCell具有SystemInformationBlockType21和SystemInformationBlockType26的有效版本（如果廣播）； 2> 如果由上層配置成在主要頻率上或在v2x-InterFreqInfoList（如果包含於PCell的SystemInformationBlockType21或SystemInformationBlockType26中）中包含的一個或複數個頻率上接收V2X側鏈路通訊： 3> 如果UE從最後一次進入RRC_CONNECTED狀態開始就不傳送SidelinkUEInformation消息；或 3> 如果從UE最後一次傳送SidelinkUEInformation消息開始，UE就連結到未廣播包含sl-V2X-ConfigCommon的SystemInformationBlockType21的PCell；或 3> 如果SidelinkUEInformation消息的最後一次傳送不包含v2x-CommRxInterestedFreqList；或如果從SidelinkUEInformation消息的最後一次傳送開始，由上層配置成接收V2X側鏈路通訊的頻率就已改變： 4> 根據5.10.2.3發起SidelinkUEInformation消息的傳送以指示感興趣的V2X側鏈路通訊接收頻率； 2> 否則： 3> 如果SidelinkUEInformation消息的最後一次傳送包含v2x-CommRxInterestedFreqList： 4> 根據5.10.2.3發起SidelinkUEInformation消息的傳送以指示對V2X側鏈路通訊接收不再感興趣； 2> 如果由上層配置成在主要頻率上或在v2x-InterFreqInfoList（如果包含於PCell的SystemInformationBlockType21或SystemInformationBlockType26中）中包含的一個或複數個頻率上傳送V2X側鏈路通訊： 3> 如果UE從最後一次進入RRC_CONNECTED狀態開始就不傳送SidelinkUEInformation消息；或 3> 如果從UE最後一次傳送SidelinkUEInformation消息開始，UE就連結到未廣播包含sl-V2X-ConfigCommon的SystemInformationBlockType21的PCell；或 3> 如果SidelinkUEInformation消息的最後一次傳送不包含v2x-CommTxResourceReq；或如果從SidelinkUEInformation消息的最後一次傳送開始，v2x-CommTxResourceReq所承載的訊息就已改變： 4> 根據5.10.2.3發起SidelinkUEInformation消息的傳送以指示UE所需的V2X側鏈路通訊傳送資源； 2> 否則： 3> 如果SidelinkUEInformation消息的最後一次傳送包含v2x-CommTxResourceReq： 4> 根據5.10.2.3發起SidelinkUEInformation消息的傳送以指示不再需要V2X側鏈路通訊傳送資源； - SidelinkUEInformation SidelinkUEInformation消息用於向eNB指示側鏈路訊息。信令無線承載：SRB1 RLC-SAP：AM 邏輯通道：DCCH 方向：UE到E-UTRAN SidelinkUEInformation消息 -- ASN1START … SidelinkUEInformation-v1430-IEs ::= SEQUENCE { v2x-CommRxInterestedFreqList-r14 SL-V2X-CommFreqList-r14 OPTIONAL, p2x-CommTxType-r14 ENUMERATED {true} OPTIONAL, v2x-CommTxResourceReq-r14 SL-V2X-CommTxFreqList-r14 OPTIONAL, nonCriticalExtension SidelinkUEInformation-v1530-IEs OPTIONAL } SidelinkUEInformation-v1530-IEs ::= SEQUENCE { reliabilityInfoListSL-r15 SL-ReliabilityList-r15 OPTIONAL, nonCriticalExtension SEQUENCE {} OPTIONAL } … SL-V2X-CommFreqList-r14 ::= SEQUENCE (SIZE (1..maxFreqV2X-r14)) OF INTEGER (0..maxFreqV2X-1-r14) SL-V2X-CommTxFreqList-r14 ::= SEQUENCE (SIZE (1..maxFreqV2X-r14)) OF SL-V2X-CommTxResourceReq-r14 SL-V2X-CommTxResourceReq-r14 ::= SEQUENCE { carrierFreqCommTx-r14 INTEGER (0.. maxFreqV2X-1-r14) OPTIONAL, v2x-TypeTxSync-r14 SL-TypeTxSync-r14 OPTIONAL, v2x-DestinationInfoList-r14 SL-DestinationInfoList-r12 OPTIONAL } -- ASN1STOP

SidelinkUEInformation 欄位描述

carrierFreqCommTx 指示UE感興趣傳送V2X側鏈路通訊的頻率的索引。值1對應於在SIB21中廣播的v2x-InterFreqInfoList中的第一條目的頻率，值2對應於在SIB21中廣播的v2x-InterFreqInfoList中的第二條目的頻率等。值0對應於PCell的頻率。

commRxInterestedFreq 指示UE感興趣接收側鏈路通訊的頻率。

commTxResourceReq 指示UE感興趣傳送非中繼相關的側鏈路通訊的頻率以及UE請求E-UTRAN為其分配專用資源的一對多側鏈路通訊傳送目的地。註1。

reliabilityInfoListSL 指示與要傳送用於V2X側鏈路通訊的所報告業務相關聯的可靠性（即，PPPR[9]）。

v2x-CommRxInterestedFreqList 指示UE感興趣接收V2X側鏈路通訊的頻率的索引。值1對應於在SIB21中廣播的v2x-InterFreqInfoList中的第一條目的頻率，值2對應於在SIB21中廣播的v2x-InterFreqInfoList中的第二條目的頻率等。值0對應於PCell的頻率。

v2x-DestinationInfoList 指示V2X側鏈路通訊的目的地。

v2x-TypeTxSync 指示UE所使用的同步參考。

3GPP TS 23.303陳述： 5.1.1.5.2 PC5信令協議圖例： - 在TS 36.300[17]中指定PDCP/RLC/MAC/PHY功能性。 - PC5信令協議用於透過PC5的控制面信令（例如，如本說明書中的其它地方所描述，透過PC5建立、維護和釋放安全層2鏈路、TMGI監視請求、細胞ID通知請求等）。 - 在PDCP標頭中的SDU類型欄位（3個位）用於區分IP、ARP和PC5信令協定。一對一通訊不支援ARP。 - 在單播目的地層2 ID上發送PC5信令協定消息。 [標題為“PC5信令協議棧”的3GPP TS 23.303 V15.1.0的圖5.1.1.5.3-1重製為第14圖]

3GPP R2-1904707陳述：對於SL單播，允許使用相同或不同源ID在相同UE對之間建立複數個鏈路。

SA2 TS 23.287: 5.6.1.4 透過PC5參考點進行的單播模式V2X通訊的標識符 UE可以與對等UE建立複數個單播鏈路並且將相同或不同源層2 ID用於這些單播鏈路。編者註：可以基於RAN WG回饋要求標識符描述的進一步更新。

此設計的目標是為上層鏈路管理保持一定的靈活性。然而，我們預見在存取層處的鏈路管理受到一些關鍵影響。例如，不清楚對等UE是否可以理解不同源ID是否指代相同傳送器UE。因此，對於UE而言，知曉經由一個鏈路接收到的UE能力是否也可以應用于其它鏈路將是有問題的。此外，對於相同UE對之間的所有鏈路，在存取層處具有鏈路管理，例如RLM/RLF似乎是不必要的。關於L1 ID，在用於具有不同源L2 ID的不同鏈路的相同UE對之間，對應L1 ID也可以不同。然而，我們認為這不是必需的並且可能會導致其它程序，例如CSI報告的問題。首先，從封包過濾角度來看，接收器UE將對來自對等UE的所有封包進行解碼，即使那些封包屬於不同鏈路。第二，在相同UE對之間的不同鏈路之間，通道條件總是相同的。因此，對於從相同UE對之間的不同源/目的地L1 ID推斷出的不同鏈路，獲取CSI報告是沒有意義的。觀察結果4 對於SL單播，UE可以與對等UE建立複數個單播鏈路並且將相同或不同源層2 ID用於這些單播鏈路。相對於UE能力交換、RLM/RLF程序和CSI報告預見對存取層設計的影響。提議5 RAN2研究允許一個UE使用複數個L2源ID與相同對等UE進行通訊的影響。如果需要，RAN2將LS發送到SA2以闡明並回饋RAN2的觀點。

3GPP R2-1904094陳述： 2.1 用於NR Uu和LTE SL中的RB建模的預備性措施在NR Uu中，配置有RLC AM的無線承載是雙向承載，其包含一個PDCP實體、一個RLC實體和一個邏輯通道（為簡單起見，本論文不考慮PDCP重複情況）。RLC實體由傳送側和接收側組成。經由相同RLC實體和相同邏輯通道（即，具有相同LCID）傳送和接收RLC資料PDU和RLC狀態報告（SR）。在圖1中說明此種雙向無線承載的建模。 [標題為“具有RLC AM的雙向Uu RB”的3GPP R2-1904094的圖1重製為第15圖] 在LTE SL中，SLRB僅支援RLC UM。每個SLRB的LCID在一個源層2ID（SRC L2 ID）和目的地層2ID（DST L2 ID）組合的範圍內是唯一的，無論對於D2D通訊中的單播和組播還是對於V2X SL通訊中的廣播。因此，可以理解，每個SL無線承載由其相關聯SL LCH的{LCID,SRC L2 ID,DST L2ID}的組合標識。這表示在UE內，在單播鏈路中用於Tx以及用於Rx的任何SLRB可以從不相同，因為前者由{SRC L2 ID,DST L2ID}={UE自身的UE ID、對等體的UE ID}標識，但是後者由{SRC L2 ID、DST L2ID}={對等體的UE ID、UE自身的UE ID}標識（即，以不同次序）。例如，相對於圖2中的UE1，用於到UE2的Tx的SLRB由{UE1 ID,UE2 ID}標識，然而用於從UE2的Rx的SLRB由{UE2 ID,UE1ID}標識。這表示SL無線承載以及LTE SL單播中的其相關聯PDCP/RLC實體和SL LCH是單向的，僅用於傳送或僅用於接收。在圖2中說明此單向承載的建模。這種單向建模在LTE SL中是可行的，一個重要原因是僅RLC UM應用於STCH，使得RLC實體需要僅用於傳送或接收，而不需要執行傳送和接收。[ 標題為“具有RLC UM的單向SL RB”的3GPP R2-1904094的圖2重製為第16圖] 2.2 用於SL中的RLC AM的雙向與單向SLRB 為了在NR單播中支援NR SLRB的RLC AM（包含用於UP資料的SL DRB以及用於PC5 RRC的SL SRB），需要討論的第一問題是具有RLC AM的SLRB應建模為單向承載還是雙向承載。隨後，這充當所有其它詳細階段3設計的本質。 ■ 選項1：用於RLC AM的單向SLRB 此選項正嘗試盡可能地重新使用LTE SL中具有RLC UM的單向SLRB的建模，這也是協定支援NR SL組播和廣播的唯一RLC模式。具體來說，每個SL RB包含一個PDCP實體、一個單向RLC實體和一個SL邏輯通道。此外，仍保持LTE SL的原理：邏輯通道的LCID在一個源層2 ID/目的地層2 ID組合內是唯一的，這表示用於Tx的SLRB/SL LCH/PDCP實體/RLC實體以及用於Rx的那些SLRB/SL LCH/PDCP實體/RLC實體仍透過相關聯{SRC L2 ID,DST L2 ID}對區分開。假設UE1正向UE2傳送資料並且UE2將相關聯RLC SR回饋到UE1，圖3示出此選項的建模。 [標題為“用於RLC AM的單向SL RB”的3GPP R2-1904094的圖3重製為第17圖]（圖3和4中的名稱“SLRBx”僅對應于討論文本中使用的“具有LCIDx的SLRB”）此種單向建模本質上應用於RLC UM，因為在TX承載上傳送的RLC資料PDU與在RX承載上接收的RLC資料PDU之間不存在關聯，因此在任何TX承載與RX承載之間不需要具有任何關係。然而，如果我們也將此種單向SLRB模型應用於RLC AM，則情況會有所不同，因為RLC資料PDU與其RLC SR之間可能需要關聯，即：是否需要（重新）傳送TxRLC實體中的RLC資料PDU取決於在對應RxRLC實體中接收的RLC SR（例如，在UE1側），並且需要將由RxRLC實體得出的SR提交給對應TxRLC實體以用於其傳送（例如，在UE2側）。因此，當所涉及SLRB被配置為RLC AM時，用於傳送RLC資料PDU（RLC SR）的TX SLRB與用於接收對應RLC SR（RLC資料PDU）的RX SLRB之間應存在連結。基於圖1中所示的實例，當UE1向UE2發起配置有RLC AM的單播業務時，UE1可能需要與UE2建立Tx SLRB和相關聯Rx SLRB兩者： a) 假設與由UE1建立（根據NW配置/預配置）的此Tx SLRB相關聯的SL LCH的LCID是LCID1，並且UE1向SL中的UE2通知此SLRB的SL LCH（標記有LCID1）根據SI相位[2]的結論配置有RLC AM； b) UE2可以與LCID1建立Rx SLRB以用於資料接收，並且因此決定具有LCID2的Tx SLRB連結到此Rx SLRB並用於傳送其RLC SR，即，在UE2中，具有LCID 1的Rx SLRB與具有LCID2的Tx SLRB連結。這還表示，從UE1的角度來看，其將透過RLC實體在具有LCID2的Rx SLRB上接收RLC SR，以獲取其在具有LCID1的Tx SLRB上發送的資料； c) 當UE1透過LCID1將RLC資料PDU傳送到UE2時，UE2（在需要時）將使用具有LCID2的Tx SLRB的RLC實體來傳送與透過LCID1從UE1接收到的MAC SDU對應的SR，即，傳送SR作為標記有{LCID2、UE2的SRC L2 ID、UE1的DST L2 ID}的MAC SDU； d) 在UE1瞭解由UE2進行的以上“Tx-Rx”SLRB連結之後，在接收到載送RLC SR的MAC SDU之後，UE1知曉其從UE2傳遞並且應傳遞到具有LCID2的Rx SLRB的RLC實體。隨後，基於UE1之前瞭解的連結，RLC SR由具有LCID2的Rx SLRB的RLC實體標識並且被提交給具有LCID1的Tx SLRB作為回饋。基於以上分析，我們看到需要解決至少以下問題，以便支援RLC AM的此種單向SLRB建模：1）UE如何將Rx SLRB連結到配置有RLC AM的Tx SLRB，以使後者的RLC實體能夠發送由前者產生的RLC SR；2）單播鏈路中的兩個UE如何與此種“Tx-Rx”SLRB鏈路（如在以上項目編號b和d中）對準。觀察結果1：如果RAN2預期採用單向SLRB建模來支援單播中的RLC AM，則首先應解決至少以下問題： ● UE如何將Rx SLRB連結到配置有RLC AM的Tx SLRB，以使後者的RLC實體能夠發送由前者產生的RLC SR； ● 單播鏈路中的兩個UE如何在此種“Tx-Rx”SLRB鏈路上彼此對準？還應注意，以上操作不可避免地需要在一個UE內的SLRB之間進行某種形式的交互。當我們最終決定是否採用單向SLRB建模用於RLC AM時，可能還需要考慮此因素。觀察結果1a：單向SLRB建模可能不可避免地需要一個UE內的SLRB間操作，以支援單播中的RLC AM。 ■ 選項2：用於RLC AM的雙向SLRB建模此選項將嘗試在Uu中重新使用具有RLC AM的雙向RB的建模。具體來說，每個SLRB包含一個PDCP實體、一個雙向RLC實體和一個SL邏輯通道。此外，邏輯通道的LCID不再由{SRC L2 ID,DST L2ID}組合唯一地標識，該組合區分兩個UE之間誰是源以及誰是目的地；替代地，該LCID在一個單播連結內應該是唯一的，例如，{SRC L2 ID,DST L2ID}組合中包含的UE1 ID和UE2 ID的次序不再有區別。假設UE1正向UE2傳送資料並且UE2將相關聯RLC SR回饋到UE1，圖4示出此選項的建模。 [標題為“用於RLC AM的雙向SL RB”的3GPP R2-1904094的圖4重製為第18圖] 此種雙向SLRB建模從未應用於LTE SL中，因此類似於NR Uu並且基於我們在SI相位期間針對NR配置/預配置SLRB達成的協定，下文我們可能需要分析雙向SLRB建模的工作方式。基於圖4中所示的實例，當UE1向UE2發起配置有RLC AM的單播業務時，UE1與UE2建立如在Uu中包含Tx側和Rx側的一個雙向SLRB，而不是如在以上選項1中分別用於Tx和Rx的兩個SLRB： a) 假設與由UE1建立的此SLRB（根據NW配置/預配置）相關聯的SL LCH的LCID是在UE1與UE2之間的單播連結內唯一的LCID1，並且UE1向SL中的UE2指示此SLRB（標記有LCID1）的SL LCH根據SI相位的結論配置有RLC AM[2]； b) 隨後，根據NW配置/預配置，UE2還需要與RLC AM和LCID1建立對應SLRB。UE2中具有LCID1的此SLRB不僅從UE1中具有LCID1的SLRB接收具有其RLC實體的資料（即，RLC資料PDU），而且還將RLC SR發送到該。另外，在UE1側，具有LCID1的SLRB將透過其Rx側接收SR以用於其自身的資料傳送。這些意味著需要確保UE2在具有LCID1的SLRB上也具有RLC AM，即，在具有相同LCID的SLRB上與UE1對準； c) 當UE1透過LCID1將RLC資料PDU傳送到UE2時，UE2（在需要時）將使用具有LCID1的SLRB的RLC實體來傳送與透過相同LCID值從UE1接收到的RLC PDU對應的SR，即，傳送SR作為標記有LCID1以及UE1與UE2之間的連結ID的MAC SDU（例如，由{UE1 ID,UE2ID}的組合（沒有順序）標識）； d) 由於在此雙向SLRB選項中，透過LCID接收到的SR自動地應用於與相同LCID相關聯的RLC實體，因此在接收到該MAC SDU之後，UE1首先知曉此MAC SDU從UE2傳遞到其自身，並且應傳遞到具有LCID1的SLRB的RLC實體。隨後，RLC SR由UE1內具有LCID1的SLRB的RLC實體標識為先前資料傳送的回饋。基於以上分析，我們看到需要解決至少以下問題，即：如果UE已經與RLC AM建立雙向SLRB，則還根據NW/預配置如何確保其對等UE在具有相同LCID的SLRB上具有相同RLC模式（即，避免RLC模式未對準）？這是至關重要的，因為如果對等UE由NW或以下預配置配置，以與相同LCID建立基於RLC UM的SLRB，則將無法傳送ARQ回饋，因此實際上在此SLRB上不支援RLC AM。觀察結果2：如果RAN2預期採用雙向SLRB建模來支援單播中的RLC AM，則首先應解決至少此問題：如果UE中的一個已經由NR配置/預配置與RLC AM建立雙向SLRB，則如何確保其對等UE還透過相同LCID（預）配置有SLRB上的RLC AM？還應注意，特別對於UE從gNB請求專用SLRB配置的情況（例如，當UE處於RRC_CONNECTED時），可能要求UE的gNB透過遵循其對等UE的RLC模式來配置SLRB，如果對等UE之前已經與RLC AM建立相同LCID的SLRB並且將其指示給SL中的該UR。觀察結果2a：在雙向SLRB建模中，當gNB如所請求將SLRB配置到UE時（例如，當UE處於RRC_CONNECTED時），gNB可能不可避免地必須遵循在具有相同LCID的SLRB上已由其對等UE採用和指示的RLC模式。上文中分別詳細描述關於支援用於SL單播RLC AM的單向或雙向SLRB的基本問題。建議RAN2考慮到以上問題來選擇SL RLC AM支援的SLRB建模。提議2：考慮到以上觀察結果中所示的問題，RAN2決定在SL單播中採用RLC AM支援的單向SLRB建模還是雙向SLRB建模。

3GPP R2-1903227陳述：如果Rx UE需要傳送業務，則Rx UE可以使用新配置消息為（原始）Tx UE配置接收配置。這引起圖1所示的流，其中UE1是初始Tx UE並且UE2是初始Rx UE。 [標題為“在兩個方向上的PC5-RRC配置”的3GPP R2-1903227的圖1重製為第19圖] 提議4：如果Rx UE需要傳送資料，則Rx UE將新配置消息發送到具有接收配置的（前述）Tx UE。

[105bis#32]PC5-RRC信令的3GPP匯總陳述： 2.2 問題-2：AS層配置根據來自RAN2#105的結論，AS層配置僅有一個選項。 [標題為“SL AS層配置訊息流，成功”的[105bis#32]PC5-RRC信令的3GPP匯總的圖5重製為第20圖] 如果將以上案例視為成功案例，則第一個問題是失敗案例的必要性（圖中的註釋僅用於說明目的，而不能以程序的命名作為結論）。 [標題為“SL AS層配置訊息流，失敗”的[105bis#32]PC5-RRC信令的3GPP匯總圖6重製為第21圖]

如在3GPP R2-1900370中所論述，引入用於基於PC5 服務品質（Quality of Service，QoS）流以及基於PC5 QoS範本的NW配置SLRB配置和預配置SLRB配置的選項。SLRB配置可以包含SLRB ID、QoS流到SLRB映射，以及存取層（Access Stratum，AS）配置（例如，封包資料彙聚協定（Packet Data Convergence Protocol，PDCP）/無線鏈路控制（Radio Link Control，RLC）/邏輯通道（Logical Channel，LCH）配置）。例如，AS配置可以指示t-重新排序、Reordering_Window、Maximum_PDCP_SN、RLC模式（非確認模式（Unacknowledged Mode，UM）或確認模式（Acknowledged Mode，AM））、AM_Window_Size、UM_Window_Size、側鏈路邏輯通道的標識，和/或等。

為了支援NR單播中的SLRB的RLC AM，在3GPP R2-1904094中引入具有RLC AM的SLRB是否應建模為單向承載或雙向承載。在NR Uu中，配置有RLC AM的無線承載是雙向承載，包含一個PDCP實體、一個RLC實體和一個邏輯通道。RLC實體由傳送側和接收側組成。經由相同RLC實體和相同邏輯通道（即，具有相同LCID）傳送和接收RLC資料PDU和RLC狀態報告。在LTE SL中，SLRB僅支援RLC UM。每個SLRB的LCID在一個源層2ID（SRC L2 ID）和目的地層2ID（DST L2 ID）組合的範圍內是唯一的，無論對於D2D通訊中的單播和組播還是對於V2X SL通訊中的廣播。這表示SL無線承載以及LTE SL單播中的其相關聯PDCP/RLC實體和SL LCH是單向的，僅用於傳送或僅用於接收。

考慮到一個UE處於RRC空閒模式而對等UE處於RRC連結模式的情況，對於任一UE獲取兩個方向的SLRB配置（基於gNB配置或預配置）並且將其轉發到後面的另一UE似乎不是良好的解決方案。例如，UE1在RRC空閒模式下將根據預配置確定的SLRB配置（或由基站廣播的系統訊息）發送到UE2，這要求連結到UE2的gNB基於根據預配置確定的SLRB配置排程UE2。或者，UE1在RRC連結模式下將由gNB配置的SLRB配置發送到UE2，這需要在RRC空閒模式下的UE2使用由gNB配置的SLRB配置。因此，用於RLC AM的單向SLRB（使用單獨的側鏈路邏輯通道）似乎更適合此類情形。此概念也可以適用於其它情形，例如，兩個UE均處於連結模式。

給定用於RLC AM的單向SLRB，在UE1獲取Tx方向的SLRB配置（基於gNB配置或預配置）並將其轉發到UE2之後，存在一個問題，即UE1不適合開始在具有RLC AM的SLRB上傳送（PC5 QoS流的）封包，因為用於UE1的反（或相反）方向的SLRB配置尚未進行分配並且UE1默認無法從UE2接收指示RLC ACK/NACK的RLC狀態報告。根據3GPP R2-1903227，如果UE1需要將業務傳送到UE2，則UE1可以使用新配置消息為UE2配置SLRB配置以用於接收。為了為UE1配置SLRB配置以用於接收，UE2需要向gNB請求SLRB配置以用於在UE1上進行接收。類似地，UE2無法傳送對SLRB配置的請求，直到來自相同QoS流的封包到達UE2。在這種情況下，UE1無法在SLRB上傳送（PC5 QoS流的）側鏈路封包，直到側鏈路封包到達UE2，這觸發UE2將SLRB配置發送到UE1。這種情況會導致側鏈路傳送延遲。因此，當UE2從UE1接收到用於UE1至UE2方向的SLRB配置時，UE2可以請求gNB配置用於UE2至UE1方向的SLRB配置。

例如，UE1將第一SLRB配置傳送到UE2，並且第一SLRB配置指示具有RLC AM的SLRB的第一SLRB ID。回應於接收到第一SLRB配置，UE2將對SLRB配置消息的請求傳送到gNB，並且gNB將NW配置的SLRB配置提供到UE2。然後，UE2將基於NW配置的SLRB配置的第二SLRB配置傳送到UE1。關於SLRB ID，可能存在兩個選項：（1）不同SLRB ID用於單獨方向，以及（2）相同SLRB ID用於單獨方向。如果使用不同SLRB ID，則UE2可能需要在對SLRB配置消息的請求中指示第一SLRB ID；以及如果使用相同SLRB ID，則在對SLRB配置消息的請求中可能不需要第一SLRB ID，並且gNB可以為NW配置的SLRB配置中的SLRB分配第二SLRB ID。

或者，第一SLRB ID仍可以包含在對SLRB配置消息的請求中，並且gNB可以為NW配置的SLRB配置中的SLRB分配第二SLRB ID。由於第一SLRB ID和第二SLRB ID與相同PC5 QoS流相關聯，因此第一SLRB ID與第二SLRB ID配對以支援相同PC5 QoS流的RLC AM。第一SLRB ID和第二SLRB ID可能相同。

回應於從UE1接收到包含第一SLRB配置的消息，UE2可能需要向UE2回復完成消息。在這種情況下，UE2從gNB請求第二SLRB配置的另一可能時序是當下層（例如，RLC層、MAC層或PHY層）已確認完成消息的成功傳送時。可以透過例如與完成消息的傳送相關聯的RLC確認或HARQ回饋確認來確認完成消息的傳送。可以在第22圖中說明以上解決方案。

如果UE1和UE2兩者處於RRC空閒或非活動模式，則當UE2從UE1接收第一SLRB配置時，UE2不會將SLRB配置消息的請求傳送到gNB。類似地，UE1無法開始在具有RLC AM的SLRB上傳送封包，直到UE2將反（或相反）方向的SLRB配置轉發到UE1。因此，當/如果UE2從UE1接收第一SLRB配置，UE2可以根據由UE2中的gNB或預配置廣播的系統訊息得出第二SLRB配置並且將第二SLRB配置傳送到UE1。或者，當/如果回應於接收到包含第一SLRB配置的消息而將完成消息成功地傳送到UE 1，UE2可以得出第二SLRB配置。可能可以透過接收與完成消息的傳送相關聯的RLC確認或HARQ回饋確認來確認是否已成功地傳送完成消息的傳送。此概念還可以應用於UE1處於連結模式並且UE2處於空閒/非活動模式的情況。可以在第23圖中說明此解決方案。

如果UE1處於RRC空閒模式並且UE2處於RRC連結模式，則UE2可能需要將SLRB配置的請求傳送到gNB。UE2可以將基於NW配置的SLRB配置的第二SLRB配置傳送到UE1。UE1通常回應於接收到包含第二SLRB配置的消息而向UE2回復完成消息。如在[105bis#32]PC5-RRC信令的3GPP匯總中所論述，討論處理接收SLRB配置的失敗情況。如果回應於傳送包含第二SLRB配置的消息，UE2從UE1接收失敗消息，則UE2可能需要向gNB通知此失敗情況並且gNB可以發佈NW配置的SLRB配置。這種情況將會引起信令開銷。

另一信令流可以是：兩個UE可以首先完成彼此交換SLRB配置（可以從系統訊息或預配置得出來自每個UE的每個SLRB配置），並且處於RRC連結模式的UE隨後傳送消息，該消息用於請求與單播鏈路上的側鏈路傳送相關的配置（包含例如，QoS流ID至SLRB ID的映射、SLRB ID至LCG的映射和/或等，其中SLRB ID由UE分配並且LCG的標識由gNB分配）。用於請求與單播鏈路上的側鏈路傳送相關的配置的消息可以包含例如，SLRB ID、PC5 QoS流ID和/或等。

例如，UE1將第一SLRB配置傳送到UE2，並且第一SLRB配置指示具有RLC AM的SLRB的第一SLRB ID。回應於接收到包含第一SLRB配置的消息，UE2將完成消息傳送到UE1。然後，UE2將第二SLRB配置傳送到UE1，並且第二SLRB配置指示具有RLC AM的SLRB的第二SLRB ID（或第一SLRB ID）。回應於接收到包含第二SLRB配置的消息，UE1將完成消息傳送到UE2。在接收到完成消息後，UE2將用於請求與單播鏈路上的側鏈路傳送相關的配置的消息傳送到gNB，然後gNB將與單播鏈路上的側鏈路傳送相關的配置提供到UE1。可以在第24圖中說明此解決方案。

第25圖是從第一UE的角度請求與第二UE的單播鏈路的SLRB配置的根據一個示例性實施例的流程圖2500。在步驟2505中，第一UE從第二UE接收第一消息，其中該第一消息包含單播鏈路的第一SLRB配置。在步驟2510中，當第一UE接收接收到第一消息，或與第一消息相關聯的完成消息成功傳送到第二UE被確認時，第一UE將第二消息傳送到網路節點以請求單播鏈路的第二SLRB配置。

在一個實施例中，第一UE可以從網路節點接收第三消息，其中第三消息包含第二SLRB配置。第一UE還可以將第四消息傳送到第二UE，其中第四消息包含第二SLRB配置。

在一個實施例中，第一消息可以包含用於單播鏈路的PC5 QoS流的標識。第二消息可以包含PC5 QoS流的標識。

在一個實施例中，第一SLRB配置可以應用於從第二UE接收封包，並且第二SLRB配置可以應用于將封包傳送到第二UE。第一消息可以是PC5 RRC消息。第四消息可以是PC5 RRC消息。

在一個實施例中，第一UE可以處於RRC_CONNECTED。網路節點可以是基站（例如，gNB）。

返回參考第3圖和第4圖，在第一UE的一個示例性實施例中，裝置300包含存儲於記憶體310中的程式碼312。CPU 308可以執行程式碼312以使第一UE能夠（i）從第二UE接收第一消息，其中該第一消息包含單播鏈路的第一SLRB配置，以及（ii）當第一UE接收到第一消息，或與第一消息相關聯的完成消息成功傳送到第二UE被確認時，將第二消息傳送到網路節點以請求單播鏈路的第二SLRB配置。此外，CPU 308可以執行程式碼312以執行所有上述作動和步驟或本文中描述的其它作動和步驟。

第26圖是從第一UE的角度的請求與第二UE的單播鏈路的SLRB配置的根據一個示例性實施例的流程圖2600。在步驟2605中，第一UE從第二UE接收第一消息，其中該第一消息包含單播鏈路的第一SLRB配置。在步驟2610中，當接收到第一消息，或與第一消息相關聯的完成消息成功傳送到第二UE被確認時，第一UE將第二消息傳送到網路節點以請求單播鏈路的第二SLRB配置。在步驟2615中，第一UE從網路節點接收第三消息，其中第三消息包含第二SLRB配置。

在一個實施例中，第一UE可以將第四消息傳送到第二UE，其中該第四消息包含第二SLRB配置。第一消息可以包含用於單播鏈路的PC5 QoS流的標識。第二消息可以包含PC5 QoS流的標識。第三消息可以包含PC5 QoS流的標識。

在一個實施例中，第一消息可以包含與第一SLRB配置相關聯的第一SLRB的標識。第二消息可以包含與第二SLRB配置相關聯的第二SLRB的標識。第二SLRB的標識可以由第一UE分配。第二SLRB的標識可以等於第一SLRB的標識。

在一個實施例中，第二消息可以不包含與第二SLRB配置相關聯的第二SLRB的標識。第二SLRB的標識可以由網路節點分配。

在一個實施例中，第三消息可以包含與第二SLRB配置相關聯的第二SLRB的標識。第四消息可以包含用於指示第一SLRB配置與第二SLRB配置之間的關聯的訊息。

在一個實施例中，第一SLRB配置可以應用於從第二UE接收封包，並且第二SLRB配置可以應用于將封包傳送到第二UE。網路節點可以是基站（例如，gNB）。

在一個實施例中，第一消息和/或第四消息可以是PC5 RRC消息。第二消息可以是包含UE輔助訊息的RRC消息。第三消息可以是RRC重新配置消息。

在一個實施例中，第一UE可以處於RRC_CONNECTED。第二UE可以處於RRC_CONNECTED、RRC_IDLE或RRC_INACTIVE。第一SLRB和/或第二SLRB可以與PC5 QoS流的標識相關聯。

在一個實施例中，回應於接收到第一消息，可以由第一UE將完成消息傳送到第二UE。可以基於與完成消息相關聯的RLC確認或HARQ回饋確認來確認與第一消息相關聯的完成消息到第二UE的成功傳送。

返回參考第3圖和第4圖，在第一UE的一個示例性實施例中，裝置300包含存儲於記憶體310中的程式碼312。CPU 308可以執行程式碼312以使第一UE能夠（i）從第二UE接收第一消息，其中第一消息包含單播鏈路的第一SLRB配置，（ii）當接收到第一消息，或與第一消息相關聯的完成消息成功傳送到第二UE被確認時，將第二消息傳送到網路節點以請求單播鏈路的第二SLRB配置，以及（iii）從網路節點接收第三消息，其中第三消息包含第二SLRB配置。此外，CPU 308可以執行程式碼312以執行所有上述作動和步驟或本文中描述的其它作動和步驟。

上文已經描述了本發明的各種方面。應明白，本文中的教示可以透過廣泛多種形式實施，且本文中所公開的任何具體結構、功能或這兩者僅是代表性的。基於本文中的教示，所屬領域的技術人員應瞭解，本文公開的方面可以獨立於任何其它方面實施，且兩個或更多個這些方面可以各種方式組合。舉例來說，可以使用本文中所闡述的任何數目個方面來實施設備或實踐方法。另外，可以使用除了在本文中所闡述的一個或複數個方面之外或不同於該方面的其它結構、功能或結構和功能來實施此種設備或實踐此種方法。作為上述概念中的一些的實例，在一些方面中，可以基於脈衝重複頻率建立並行通道。在一些方面中，可以基於脈衝位置或偏移建立並行通道。在一些方面中，可以基於跳時序列建立並行通道。在一些方面中，可以基於脈衝重複頻率、脈衝位置或偏移、以及跳時序列建立並行通道。

所屬領域的技術人員將理解，可以使用多種不同技術及技藝中的任一個來表示訊息和訊號。舉例來說，可通過電壓、電流、電磁波、磁場或磁粒子、光場或光粒子或其任何組合來表示在整個上文描述中可能參考的數據、指令、命令、訊息、訊號、位元、符號和碼片。

所屬領域的技術人員將進一步瞭解，結合本文中所公開的方面描述的各種說明性邏輯塊、模組、處理器、構件、電路和演算法步驟可被實施為電子硬體（例如，數位實施方案、類比實施方案或兩者的組合，其可使用源解碼或某一其它技術設計）、併入有指令的各種形式的程序或設計代碼（其可在本文為方便起見稱為“軟體”或“軟體模組”）或兩者的組合。為清晰地說明硬體與軟體的此可互換性，上文已大體就各種說明性元件、塊、模組、電路和步驟的功能性加以描述。這類功能性是以硬體來實施還是以軟體來實施取決於特定應用和強加於整個系統的設計約束。熟練的技術人員可針對每一具體應用以不同方式來實施所描述的功能性，但這樣的實施決策不應被解釋為會引起脫離本公開的範圍。

另外，結合本文中所公開的方面描述的各種說明性邏輯塊、模組和電路可以在積體電路（“integrated circuit，IC”）、存取終端或存取點內實施或由該積體電路、存取終端或存取點執行。IC可以包括通用處理器、數位訊號處理器（DSP）、專用積體電路（ASIC）、現場可程式設計閘陣列（FPGA）或其它可程式設計邏輯裝置、離散門或電晶體邏輯、離散硬體元件、電氣元件、光學元件、機械元件，或其經設計以執行本文中所描述的功能的任何組合，且可以執行駐留在IC內、在IC外或這兩種情況下的代碼或指令。通用處理器可以是微處理器，但在替代方案中，處理器可以是任何常規處理器、控制器、微控制器或狀態機。處理器還可實施為計算裝置的組合，例如DSP與微處理器的組合、多個微處理器的組合、一個或多個微處理器結合DSP核心，或任何其它此類配置。

應理解，在任何所公開的過程中的步驟的任何特定次序或層級都是示例方法的實例。應理解，基於設計偏好，過程中的步驟的特定次序或層級可以重新佈置，同時保持在本公開的範圍內。隨附的方法權利要求以示例次序呈現各種步驟的元素，且並不有意限於所呈現的特定次序或層級。

結合本文中公開的方面所描述的方法或演算法的步驟可直接用硬體、用處理器執行的軟體模組或用這兩者的組合體現。軟體模組（例如，包含可執行指令和相關數據）和其它數據可駐留在數據記憶體中，例如RAM記憶體、快閃記憶體、ROM記憶體、EPROM記憶體、EEPROM記憶體、寄存器、硬碟、可裝卸式磁片、CD-ROM，或此項技術中已知的任何其它形式的電腦可讀存儲介質。示例存儲介質可以耦合到例如電腦/處理器等機器（為方便起見，該機器在本文中可以稱為“處理器”），使得該處理器可以從存儲介質讀取訊息（例如，代碼）且將訊息寫入到存儲介質。示例存儲介質可與處理器形成一體。處理器及存儲介質可駐留在ASIC中。ASIC可以駐留在使用者設備中。在替代方案中，處理器和存儲介質可以作為離散元件駐留於使用者設備中。此外，在一些方面中，任何合適的電腦程式產品可包括電腦可讀介質，該電腦可讀介質包括與本公開的各方面中的一個或多個方面相關的代碼。在一些方面中，電腦程式產品可以包括封裝材料。

雖然已結合各種方面描述本發明，但應理解本發明能夠進行進一步修改。本申請意圖涵蓋對本發明的任何改變、使用或調適，這通常遵循本發明的原理且包含對本公開的此類偏離，偏離處於在本發明所屬的技術領域內的已知及慣常實踐的範圍內。

100:存取網路 104,106,108,110,112,114:天線 116:存取終端 118:反向鏈路 120:前向鏈路 122:存取終端 124:反向鏈路 126:前向鏈路 210:傳送器系統 212:數據源 214:TX數據處理器 220:TX MIMO處理器 222a:222t:傳送器 224a:224t:天線 230:處理器 232:記憶體 236:數據源 238:TX數據處理器 242:RX數據處理器 240:解調器 250:接收器系統 252a:252r:天線 254a:254r:接收器 260:RX數據處理器 270:處理器 272:記憶體 280:調變器 300:通訊裝置 302:輸入裝置 304:輸出裝置 306:控制電路 308:中央處理器 310:記憶體 312:程式碼 314:收發器 400:應用層 402:層3 404:層2 406:層1 2500:流程圖 2505,2510:步驟 2600:流程圖 2605,2610,2615:步驟

第1圖展示根據一個示範性實施例的無線通訊系統的圖式。第2圖是根據一個示範性實施例的傳送器系統（也被稱為存取網絡）和接收器系統（也被稱為使用者設備或UE）的方塊圖。第3圖是根據一個示範性實施例的通訊系統的功能方塊圖。第4圖是根據一個示範性實施例的第3圖的程式碼的功能方塊圖。第5圖是3GPP TR 23.786 V1.0.0的圖6.11.3.1-1的重製。第6圖是3GPP TR 23.786 V1.0.0的圖6.11.3.1-2的重製。第7圖是3GPP TR 23.786 V1.0.0的圖6.11.3.1-2的重製。第8圖是3GPP TR 23.786 V1.0.0的圖6.19.2.1.2-1的重製。第9圖是3GPP R2-1900370的圖A-1的重製。第10圖是3GPP R2-1900370的圖A-2的重製。第11圖是3GPP R2-1900370的圖A-3的重製。第12圖是3GPP TS 36.300 V15.3.0的圖6-3的重製。第13圖是3GPP 36.331 V15.3.0的圖5.10.2-1的重製。第14圖是3GPP TS 23.303 V15.1.0的圖5.1.1.5.3-1的重製。第15圖是3GPP R2-1904094的圖1的重製。第16圖是3GPP R2-1904094的圖2的重製。第17圖是3GPP R2-1904094的圖3的重製。第18圖是3GPP R2-1904094的圖4的重製。第19圖是3GPP R2-1903227的圖1的重製。第20圖是[105bis#32]PC5-RRC信令的3GPP匯總的第5圖的重製。第21圖是[105bis#32]PC5-RRC信令的3GPP匯總的第6圖的重製。第22圖是根據一個示例性實施例的圖式。第23圖是根據一個示例性實施例的圖式。第24圖是根據一個示例性實施例的圖式。第25圖是根據一個示範性實施例的流程圖。第26圖是根據一個示範性實施例的流程圖。

2500:流程圖

2505,2510:步驟

Claims

一種用於一第一使用者設備請求與一第二使用者設備的一單播鏈路的側鏈路無線電承載配置的方法，包括：從該第二使用者設備接收第一消息，其中該第一消息包含該單播鏈路的一第一側鏈路無線電承載配置以及該第一側鏈路無線電承載配置包括指示用於從該第二使用者設備到該第一使用者設備的傳輸的一第一側鏈路無線電承載的一無線電鏈路控制模式的訊息；當該第一使用者設備接收到該第一消息，或與該第一消息相關聯的一完成消息成功傳送到該第二使用者設備被確認時，將一第二消息傳送到一網路節點以請求用於該單播鏈路從該第一使用者設備到該第二使用者設備的傳輸的一第二側鏈路無線電承載的一第二側鏈路無線電承載配置，其中該第二消息包括一PC5 QoS流的標識；以及從該網路節點接收一第三消息，其中該第三消息包含該第二側鏈路無線電承載配置以及該第二側鏈路無線電承載配置包括指示該PC5 QoS流的標識和該無線電鏈路控制模式的訊息。
如請求項1所述的方法，進一步包括：將一第四消息傳送到該第二使用者設備，其中該第四消息包含該第二側鏈路無線電承載配置。
如請求項1所述的方法，該第一消息包含用於該單播鏈路的PC5服務品質流的一標識。
如請求項1所述的方法，該第一側鏈路無線電承載配置應用於從該第二使用者設備接收封包，並且該第二側鏈路無線電承載配置應用于將封包傳送到該第二使用者設備。
如請求項1所述的方法，該第一消息是一PC5無線電資源控制消息。
如請求項2所述的方法，該第四消息是一PC5無線電資源控制消息。
如請求項1所述的方法，該第一使用者設備處於RRC_CONNECTED。
如請求項1所述的方法，該網路節點是一基站。
一種用於請求與一第二使用者設備的單播鏈路的側鏈路無線電承載配置的一第一使用者設備，包括：一控制電路；一處理器，該處理器安裝在該控制電路中；以及一記憶體，該記憶體安裝在該控制電路中並且可操作地耦合到該處理器；其中該處理器執行存儲於該記憶體中的一程式碼以：從該第二使用者設備接收一第一消息，其中該第一消息包含該單播鏈路的一第一側鏈路無線電承載配置以及該第一側鏈路無線電承載配置包括指示用於從該第二使用者設備到該第一使用者設備的傳輸的一第一側鏈路無線電承載的一無線電鏈路控制模式的訊息；當接收到該第一消息，或與該第一消息相關聯的一完成消息成功傳送到該第二使用者設備被確認時，將一第二消息傳送到一網路節點以請求用於該單播鏈路從該第一使用者設備到該第二使用者設備的傳輸的一第二側鏈路無線電承載的一第二側鏈路無線電承載配置，其中該第二消息包括一PC5 QoS流的標識；以及從該網路節點接收一第三消息，其中該第三消息包含該第二側鏈路無線電承載配置以及該第二側鏈路無線電承載配置包括指示該PC5 QoS流的標識和該無線電鏈路控制模式的訊息。
如請求項9所述的第一使用者設備，該處理器進一步執行存儲於該記憶體中的程式碼以：將一第四消息傳送到該第二使用者設備，其中該第四消息包含該第二側鏈路無線電承載配置。
如請求項9所述的第一使用者設備，該第一消息包含用於該單播鏈路的一PC5服務品質流的標識。
如請求項9所述的第一使用者設備，該第一側鏈路無線電承載配置應用於從該第二使用者設備接收封包，並且該第二側鏈路無線電承載配置應用于將封包傳送到該第二使用者設備。
如請求項9所述的第一使用者設備，該第一消息是一PC5無線電資源控制消息。
如請求項10所述的第一使用者設備，該第四消息是一PC5無線電資源控制消息。
如請求項9所述的第一使用者設備，該第一使用者設備處於RRC_CONNECTED。
如請求項9所述的第一使用者設備，該網路節點是一基站。