TW201922038A

TW201922038A - 條件式無線電資源控制確認訊息傳遞之方法及其裝置

Info

Publication number: TW201922038A
Application number: TW107134474A
Authority: TW
Inventors: 波喬麥可康森恩; 林香君; 曾理銓; 吉列斯查比特
Original assignee: 聯發科技股份有限公司
Priority date: 2017-09-29
Filing date: 2018-09-28
Publication date: 2019-06-01
Also published as: US20190104564A1; CN110050472A; WO2019062875A1; TWI696405B

Abstract

描述了關於條件式無線電資源控制（RRC）確認訊息傳遞之各種示例和方案。使用者設備（UE）與無線網路之網路節點通訊。在與網路節點通訊時，UE向該網路節點發送第一訊息，並且從該網路節點接收第二訊息，以回應於該第一訊息之該發送。UE還確定是否向該網路節點發送第三訊息，以確認接收該第二訊息。也就是說，作為接收該第二訊息之確認之第三訊息之該發送係有條件的或者係可選的，從而減少信令負荷。

Description

無線通訊之條件式無線資源控制確認傳訊

本發明係總體上有關於無線通訊，以及，更具體地，係有關於無線通訊中條件式無線電資源控制（radio resource control，RRC）確認訊息傳遞。

除非另有說明，否則本節中描述之方法不作為後面列出的申請專利範圍之先前技術，以及，不因包含在本節中而被認為係先前技術。

為了支援諸如窄帶物聯網（Narrowband Internet of Things，NB-IoT）或機器類型通訊（Machine Type Communication，MTC）優化之長期演進（Long-Term Evolution，LTE）之高度優化之通訊系統，期望更積極地減少信令負荷之新方法，從而減少信令以延長使用者設備（user equipment，UE）之電池壽命。隨著低電池消耗之需求越來越尖銳，每次發送都具有潛在之重要性。

下面的發明內容僅係說明性的，而不旨在以任何方式進行限制。也就是說，提供下文發明內容來介紹本文所述之新穎且非顯而易見技術之概念、要點、益處和有益效果。所選實施方式在下文詳細描述中進一步描述。因此，下文發明內容並不旨在標識所要求保護主題之基本特徵，也不旨在用於確定所要求保護主題之範圍。

本發明提出了關於無線通訊中條件式RRC確認訊息傳遞之複數個方案、解決方法、技術、方法以及裝置。可以相信的是，所提出之方案、解決方法、技術、方法以及裝置將會導致減少信令負荷，進而提升整個系統性能並且增加UE之電池壽命。

在一方面，一種方法可以包含UE之處理器與無線網路之網路節點通訊。在與該網路節點通訊時，該方法可以包含處理器向該網路節點發送第一訊息並且從該網路節點接收第二訊息，以回應於該第一訊息之該發送。該方法還可以包含處理器確定是否向該網路節點發送第三訊息，以確認接收該第二訊息。

在一方面，一種裝置可以包含收發器以及耦接於該收發器之處理器。該收發器用於與無線網路之網路節點通訊。該處理器用於（a）經由該收發器向該網路節點發送第一訊息；（b）經由該收發器，從該網路節點接收第二訊息，以回應於發送該第一訊息；以及（c）確定是否向網路節點發送第三訊息，以確認接收該第二訊息。

值得注意的是，雖然本文提供之描述包含諸如物聯網（Internet-of-Things，IoT）和NB-IoT中之某些無線電存取技術、網路和網路拓撲之上下文，然而本文所提出之概念、方案及其任何變形/衍生可以於、用於或透過其他任何類型之無線電存取技術、網路和網路拓撲實施，例如但不限於，第五代、新無線電（new radio，NR）、長期演進（Long-Term Evolution，LTE）、先進長期演進（LTE-Advanced）、先進長期演進升級版（LTE-Advanced Pro）。因此，本發明之範圍不限於本文所述之示例。

本文公開了所要求保護之主題之詳細實施例和實施方式。然而，應當理解的是，所公開之實施例和實施方式僅僅係可以以各種形式實現之所要求保護之主題之說明。然而，本發明可以以許多不同形式來實現，並且不應該被解釋為限於本文所闡述之示例性實施例和實施方式。相反，提供這些示例性實施例和實施方式以使本發明之描述全面和完整，並且向所屬領域具有通常知識者充分地傳達本發明之範圍。在下文描述中，可以省略公知特徵和技術之細節，以避免不必要地模糊所呈現之實施例和實施方式。
概述

依據本發明之實施方式涉及關於用於減少信令負荷以及改善系統性能之無線通訊中之條件式RRC確認訊息之各種技術、方法、方案和/或解決方法。依據本發明，複數個可解決方法可以分開或一併實施。也就是說，雖然該等可能解決方法在下文分開描述，然而該等可能解决方案中之兩個或複數個可以以一個組合形式或另一個組合形式實施。

在當前之第三代合作夥伴計畫（3^rd -Generation Partnership Project，3GPP）系統中，考慮使用信令魯棒性需求指定信令進程。此外，信令進程被預先分類並且硬編碼為單向指示進程、雙向進程和/或具有雙向交互以及確認訊息之三向進程。在當前系統中，可選地，資訊被建模為特定信令訊息中資訊元素之缺失或存在。此外，在當前系統中，用於建立和配置信令連接所交換之第一訊息通常使用非常簡單之預先配置之固定裝置，並且依據最糟糕情況之場景來確定尺度。也就是說，用於建立和配置信令連接所交換之第一訊息之大小係固定的，以便處理非常糟糕之無線電狀況。然而，存在一個問題，即當前之原理、設計和方法傾向於產生大量訊息，從而導致不期望之信令負荷。

依據3GPP規範，當前RRC連接建立或連接恢復進程係三向進程，該三向進程應用於UE與無線網路（例如，LTE或5G/NR行動網路）之基地台（例如，eNodeB或gNB）之間之通訊之存取階段。該進程通常包含UE和基地台之間之以下步驟：
1.從UE到基地台（訊息3）：RRC連接建立請求（CP CIoT EPS優化）或RRC連接恢復請求UP CIoT EPS優化）;
2.從基地台到UE（訊息4）：RRC連接建立或RRC連接恢復；以及
3.從UE到基地台（訊息5）：RRC連接建立確認或RRC連接恢復確認。

第1圖示出了UE 110與基地台120之間之三向握手進程之示例場景100。在場景100中，UE 310向基地台320發送請求（訊息3）以及一旦從基地台320接收回應（訊息4），UE 310就發送確認訊息（訊息5）。

第2A圖示出了建立用於CP CIoT EPS優化之RRC連接之示例場景200A。參考第2A圖，進程200A包含關於UE 210和基地台220之以下步驟：
0. UE 210向基地台220發送隨機存取前導碼（preamble），基地台220使用隨機存取回應進行回應。
1. UE 210向基地台220發送RRC連接請求訊息RRCConnectionRequest。
2. 基地台220向UE 210發送RRC連接建立訊息RRCConnectionSetup。
3. UE 210向基地台220發送RRC連接建立完成訊息RRCConnectionSetupComplete（包含上行鏈路（uplink，UL）非存取層（non-access stratum，NAS）訊息）。

第2B圖示出了建立用於UP CIoT EPS優化之RRC連接之示例場景200B。參考第2B圖，進程200B包含關於UE 210和基地台220之以下步驟：
0. UE 210向基地台220發送隨機存取前導碼，基地台220使用隨機存取回應進行回應。
1. UE 210向基地台220發送RRC連接恢復請求訊息RRCConnectionResumeRequest（包含恢復ID、恢復原因和認證標記（shortResumeMAC-I））。
2.基地台220向UE 210發送RRC連接恢復訊息RRCConnectionResume（包含下一跳接鏈結計數（NextHopChainingCount））。
3. UE 210恢復所有信令無線電承載（signaling radio bearer，SRB）和資料無線電承載（data radio bearer，DRB），重新建立存取層（access stratum，AS）安全性，並且進入RRC連接（RRC_Connected）模式。
4. UE 210向基地台220發送RRC連接恢復完成訊息RRCConnectionResumeComplete。

在訊息3之前，UE需要向基地台發送前導碼（訊息1）並經由基地台從網路接收隨機存取回應（訊息2）。

從UE發送到基地台之RRC連接請求訊息攜帶諸如UE之標識（identification of the UE，UE-ID）、建立原因、多頻聲支援資訊和多載波支援資訊之資訊。從基地台發送到UE之RRC連接建立訊息攜帶諸如專用RRC配置之資訊。從UE發送到基地台之RRC連接恢復請求訊息攜帶諸如恢復ID、恢復原因和訊息認證標記（shortResumeMAC-I）之資訊。從基地台發送到UE之RRC連接恢復訊息攜帶諸如專用RRC配置、安全控制資訊以及關於是否透過資料無線電承載-繼續標頭壓縮（drb-ContinueROHC）繼續或重置用於DRB之標頭壓縮協定上下文之指示之資訊。
繼續之 RRC 確認訊息傳遞

在上述之第三步驟（訊息5）中之訊息傳遞中，對於控制平面CIoT EPS優化，UE使用確認RRC連接成功建立之RRC連接建立完成RRCConnectionSetupComplete，以及包含服務請求和/或上行鏈路使用者資料之NAS 協定資料單元（protocol data unit，PDU）進行回應。對於使用者平面CIoT EPS優化，UE盡可能使用確認RRC連接成功恢復之RRC連接恢復完成RRCConnectionResumeComplete，以及上行鏈路緩衝狀態報告和/或UL資料向基地台進行回應。

依據本發明在所提出之方案下，對於需要更高程度優化之機器到機器（machine-to-machine，M2M）系統，只要訊息5中發送之基本資訊可以在訊息3中發送，上述第三步驟（訊息5）中之訊息傳遞可視為可選的，從而減少從UE到基地台以及UE和基地台之間之傳輸之次數。

所提出之方案係靈活的並且可以適應不同之無線電狀況和不同之無線電傳輸區塊大小。具體地，在所提出之方案下，第一請求訊息（訊息3）僅需要攜帶最通用之資訊，例如但不限於，用於附著之UE之“正常”標識，系統架構演進（System Architecture Evolution，SAE）臨時行動用戶標識（SAE temporary mobile subscriber identity，S-TMSI），或者用於暫停之UE之恢復ID加上訊息認證標記（shortResumeMAC-I），以及UL資料。此外，在所提出之方案下，當請求訊息中之基本資訊不足時，確認訊息（訊息5）僅需要攜帶用於特定情況之可選資訊和附加UE位址資訊。UE確定是否發送訊息5取決於訊息4中之指示。例如，在所提出之方案下，當UE變換到連接到核心網路之另一部分之基地台時，UE可以發送確認訊息（訊息5）。

在所提出之方案下，基地台可以確定何時需要來自UE之附加資訊，從而使得UE需要發送確認訊息（訊息5）以提供這樣之附加資訊。因此，基地台可以明確地請求這樣之資訊或確認訊息。可以相信的是，當應用其他增強時，所提出之方案將特別有用。例如，當複數條資料可以與具有請求（在UL方向上）和/或建立/恢復訊息（在DL方向上）之信令一起發送時，整個連接模式“會話”可以使用兩個（或三個）主要發送結束。第3圖依據本發明之實施方式示出了UE 310和基地台320之間之通用雙向握手進程之示例性場景300。在場景300中，UE 310向基地台320發送請求（訊息3），並且一旦從基地台320接收到回應（訊息4）（例如，許可請求）時，UE 310可以確定不需要發送確認訊息。因此，在場景300中沒有發送確認訊息（訊息5）。

還值得注意的是，添加一些資訊到無論如何需要發生之無線電傳輸所相關聯之代價或成本將遠小於為上述資訊創建專用傳輸之代價或成本。因此，機會主義地，在訊息3和訊息4（例如，用於諸如NAS或網際網路協定（Internet Protocol，IP）多媒體子系統（IP Multimedia Subsystem，IMS）信令之資料或更高層信令）之後無論如何都需要執行之UL傳輸之事件中，例如，由於訊息3之大小有限，UL資料不能在訊息3中發送，依據本發明所提出之方案UE可以發送確認訊息。

為了幫助更好地理解所提出之方案，下文早期資料發送（early data transmission，EDT）之上下文中提供了跳過RRC確認訊息之說明性且非限制性之示例。
用於控制平面 CIoT EPS 優化之 EDT

用於CP CIoT EPS優化之EDT之特徵如下：
•在公用控制通道（Common Control Channel，CCCH）上之UL RRC早期資料請求訊息RRCEarlyDataRequest中攜帶之NAS訊息中發送上行鏈路使用者資料；
•可選地，在CCCH上之DL早期資料完成訊息RRCEarlyDataComplete攜帶之NAS訊息中發送下行鏈路使用者資料；以及
•不需要轉換到RRC 連接。

第4A圖依據本發明之實施方式示出了用於CP CIoT EPS優化之示例EDT進程400A之示意圖。參考第4A圖，進程400A包含關於UE 410、基地台420、行動管理實體（mobile management entity，MME）430以及服務閘道（serving gateway ，S-GW）440之以下步驟：
0.一旦連接建立請求用於上層之行動發起之資料，UE 410就發起EDT進程並選擇配置用於EDT之隨機存取前導碼。
1. UE 410在CCCH上發送攜帶使用者資料之RRC早期資料請求訊息RRCEarlyDataRequest。
2. 基地台420發起S1-應用協定（S1-application protocol，S1-AP）初始UE訊息進程以轉發NAS訊息以及建立S1連接，並且基地台420可以在該進程中指示該連接被觸發用於EDT。
3. MME 430請求S-GW 440重新激活UE 410之EPS承載。
4. MME 430向S-GW 440發送上行鏈路資料。
5. 如果下行鏈路資料可用，則S-GW 440 向MME 430發送下行鏈路資料。
6. 如果從S-GW 440接收下行鏈路資料，則MME 430經由DL NAS傳輸進程向基地台420轉發資料，並且還可以指示是否期望進一步之資料。否則，MME 430可以觸發連接建立指示進程，並且還指示是否期望進一步之資料。
7. 如果不期望進一步之資料，則基地台420可以在CCCH上發送RRC早期資料完成訊息RRCEarlyDataComplete以保持UE 410處於RRC空閒（RRC_IDLE）。如果在步驟6中接收下行鏈路資料，則它們被攜帶在RRC早期資料完成訊息RRCEarlyDataComplete中。
8. 釋放S1連接並且停用EPS承載。

值得注意的是，在MME 430或基地台420確定移動UE 410進入RRC連接（RRC_Connected）模式之事件中，可以在步驟7中發送RRC連接建立訊息RRCConnectionSetup以回退到傳統RRC連接建立進程。基地台420可以丟棄訊息5中接收之零長度NAS PDU。

因此，當基地台420從UE 410接收到RRC早期資料完成訊息RRCEarlyDataComplete時，基地台420可以向UE 410發送兩個訊息中之任一個。在遵循雙向握手進程之事件中，基地台420可以在其對UE 410之回應訊息中向UE 410 發送RRC早期資料完成RRCEarlyDataComplete。然而，在基地台420確定轉換UE 410到RRC連接（RRC_connected）模式之事件中，基地台420可以在其對UE 410之回應訊息中向UE 410發送RRC連接建立RRCConnectionSetup。RRC早期資料完成RRCEarlyDataComplete和RRC連接建立RRCConnectionSetup之間之差異不僅僅在資訊元素（IE）中，而是所攜帶之上下文和/或格式也可能係不同的。無論在從基地台420到UE 410之回應訊息中發送RRC早期資料完成RRCEarlyDataComplete或是RRC連接建立RRCConnectionSetup，指示都在DL CCCH訊息中提供。

當UE 410沒有RRC連接時，RRC早期資料完成訊息RRCEarlyDataComplete可用於確認CP EDT進程成功完成。作為說明性且非限制性之示例，RRC早期資料完成訊息RRCEarlyDataComplete如下：
-- ASN1START

RRCEarlyDataComplete-r15 ::= SEQUENCE {
criticalExtensions CHOICE {
c1 CHOICE {
rrcEarlyDataComplete-r15 RRCEarlyDataComplete-r15-IEs,
spare1 NULL
},
criticalExtensionsFuture SEQUENCE {}
}
}

RRCEarlyDataComplete-r15-IEs ::= SEQUENCE {
dedicatedInfoNAS-r15 DedicatedInfoNAS OPTIONAL, -- Need ON
extendedWaitTime-r15 INTEGER (1..1800) OPTIONAL, -- Need ON
idleModeMobilityControlInfo-r15 IdleModeMobilityControlInfo OPTIONAL, -- Need OP
idleModeMobilityControlInfoExt-r15 IdleModeMobilityControlInfo-v9e0 OPTIONAL, -- Cond IdleInfoEUTRA
redirectedCarrierInfo-r15 RedirectedCarrierInfo-r15-IEs OPTIONAL, -- Need ON
nonCriticalExtension SEQUENCE {} OPTIONAL
}

RedirectedCarrierInfo-r15-IEs ::= CHOICE {
eutra-r15 ARFCN-ValueEUTRA-r9,
geran-r15 CarrierFreqsGERAN,
utra-FDD-r15 ARFCN-ValueUTRA,
cdma2000-HRPD-r15 CarrierFreqCDMA2000,
cdma2000-1xRTT-r15 CarrierFreqCDMA2000,
utra-TDD-r15 CarrierFreqListUTRA-TDD-r10
}

-- ASN1STOP

RRC連接建立訊息RRCConnectionSetup可用於建立SRB1和再一個SRB1（SRB1bis）。作為說明性且非限制性之示例，RRC連接建立訊息RRCConnectionSetup如下：
-- ASN1START

RRCConnectionSetup-NB ::= SEQUENCE {
rrc-TransactionIdentifier RRC-TransactionIdentifier,
criticalExtensions CHOICE {
c1 CHOICE {
rrcConnectionSetup-r13 RRCConnectionSetup-NB-r13-IEs,
spare1 NULL
},
criticalExtensionsFuture SEQUENCE {}
}
}

RRCConnectionSetup-NB-r13-IEs ::= SEQUENCE {
radioResourceConfigDedicated-r13 RadioResourceConfigDedicated-NB-r13,
lateNonCriticalExtension OCTET STRING OPTIONAL,
nonCriticalExtension SEQUENCE {} OPTIONAL
}

-- ASN1STOP

DL CCCH訊息類別可以包含可以在DL CCCH邏輯通道上從基地台420發送到UE 410之RRC訊息集合。作為說明性且非限制性之示例，DL CCCH訊息如下：
-- ASN1START

DL-CCCH-Message ::= SEQUENCE {
message DL-CCCH-MessageType
}

DL-CCCH-MessageType ::= CHOICE {
c1 CHOICE {
rrcConnectionReestablishment RRCConnectionReestablishment,
rrcConnectionReestablishmentReject RRCConnectionReestablishmentReject,
rrcConnectionReject RRCConnectionReject,
rrcConnectionSetup RRCConnectionSetup
},
messageClassExtension CHOICE {
c2 CHOICE {
rrcEarlyDataComplete-r15 RRCEarlyDataComplete-r15,
spare NULL
},
messageClassExtensionFuture-r15 SEQUENCE {}
}
}

-- ASN1STOP
用於使用者平面 CIoT EPS 優化之 EDT

用於UP CIoT EPS優化之EDT之特徵如下：
•在具有暫停指示之RRC連接釋放訊息RRCConnectionRelease中向UE提供NextHopChainingCount；
•在專用訊務通道（Dedicated Traffic Channel，DTCH）上發送之上行鏈路使用者資料與CCCH上之UL RRC連接恢復請求訊息RRCConnectionResumeRequest複用；以及
•可選地，專用控制通道（Dedicated Control Channel，DCCH）上之DL RRC連接釋放訊息RRCConnectionRelease與DTCH上之下行鏈路使用者資料複用。

第4B圖依據本發明之實施方式示出了用於UP CIoT EPS優化之示例EDT進程400B。參考第4B圖，進程400B包含關於UE 410、基地台420、MME 430和S-GW 440之以下步驟：
0. 一旦連接恢復請求用於上層之行動發起之資料，UE 410發起EDT進程並選擇配置用於EDT之隨機存取前導碼。
1. UE 410向基地台420發送RRC連接恢復請求訊息RRCConnectionResumeRequest，包含其恢復ID、建立原因以及認證標記。UE 410恢復所有SRB和DRB，使用先前連接之RRC連接釋放訊息RRCConnectionRelease中提供之NextHopChainingCount來導出新之安全密鑰，並重新建立AS安全性。使用者資料被加密並且被在DTCH上發送，與CCCH上之RRC連接恢復請求訊息RRCConnectionResumeRequest複用。
2. 基地台420發起S1-AP上下文恢復進程以恢復S1連接，並且重新激活S1-U承載。
3. MME 430請求S-GW 440重新激活UE 410之S1-U承載。
4. MME 430向基站420確認UE上下文恢復。
5.傳送上行鏈路資料到S-GW 440 。
6.如果下行資料可用，S-GW 440向基地台420發送下行鏈路資料。
7.如果不期望來自S-GW 440之進一步資料，則基地台420可以發起S1連接之暫停以及S1-U承載之去激活。
8.基地台420發送RRC連接釋放訊息RRCConnectionRelease以保持UE 410處於RRC空閒（RRC_IDLE）。該訊息包含由UE 410存儲之設置為RRC暫停（rrc-Suspend）之釋放原因（releaseCause），恢復ID、NextHopChainingCount以及drb-ContinueROHC。如果在步驟6中接收下行鏈路資料，則其在DTCH上被加密與DCCH上之RRC連接釋放訊息RRCConnectionRelease複用。

值得注意的是，在MME 430或基地台420確定移動UE 410到RRC連接（RRC_Connected）模式之事件中，可以在步驟7中發送RRC連接恢復訊息RRCConnectionResume以回退到RRC連接恢復進程。在這種情況下，RRC連接恢復訊息RRCConnectionResume可以係完整性保護的，並且利用在步驟1中導出之密鑰進行加密。此外，UE 410可以忽略包含在RRC連接恢復訊息RRCConnectionResume中之NextHopChainingCount。下行鏈路資料可以在DTCH上發送並且與RRC連接恢復訊息RRCConnectionResume複用。

值得注意的是，在事件中，例如， UE上下文不能在基地台中恢復，並且MME或基地台確定與UE建立RRC連接，則RRC連接建立訊息RRCConnectionSetup可以被發送到RRC連接恢復進程，以回退到傳統RRC連接建立進程。然後，可以從UE向基地台發送RRC連接建立完成訊息。
說明性實施 方式

第5圖依據本發明之實施方式示出了具有示例裝置510和示例裝置520之示例通訊環境500。為了實施本文中描述之關於用於減少信令負荷以及改善系統性能之無線通訊中之條件式RRC確認訊息之方案、技術、流程和方法，裝置510和裝置520中之每一個可以執行各種功能，包含上文所述各種方案，例如場景300、400A以及400B及下文所述流程600。裝置310係上文所述UE 410之示例實施。裝置520係上文所述基站420之示例實施。

裝置510和裝置520之每一個可以係電子裝置之一部分，可以係諸如可擕式或行動裝置、可穿戴裝置、無線通訊裝置或計算裝置等UE。例如，裝置510和裝置520之每一個可以在智慧型手機、智慧型手錶、個人數位助理、數位相機或諸如平板電腦、膝上型電腦或筆記本電腦等計算設備中實施。裝置510和裝置520之每一個還可以係機器類型裝置之一部分，可以係諸如固定或靜態裝置、家庭裝置、有線通訊裝置或計算裝置等IoT或NB-IoT裝置。例如，裝置510和裝置之每一個可以在智慧型恒溫器、智慧型冰箱、智慧型門鎖、無線揚聲器或家庭控制中心中實施。或者，裝置510和裝置520之每一個還可以以一個或複數個積體電路（Integrated circuit，IC）晶片形式實施，例如但不限於，一個或複數個單核處理器、一個或複數個多核處理器或一個或複數個複雜指令集計算（Complex-Instruction-Set-Computing，CISC）處理器。裝置510和裝置520之每一個至少包含第5圖中所示組件中之一部分，例如，分別為處理器512和處理器522。裝置510和裝置520之每一個可以進一步包含與本發明提出之方案無關之一個或複數個其它組件（例如，內部電源、顯示設備和/或使用者介面設備），但為簡化和簡潔，裝置510之該等其他組件沒有在第5圖中描述，也沒有在下文描述。

在一些實施方式中，裝置510和裝置520中至少一個可以係電子裝置之一部分，可以係網路節點，例如，TRP、基地台、小區、路由器或閘道器。例如，裝置510和裝置520中至少一個可以在LTE、LTE-Advanced或 LTE-Advanced Pro 網路中之eNodeB中或 5G、NR、IoT和NB-IoT網路中之gNB中實施。或者，裝置510和裝置520中至少一個還可以以一個或複數個IC晶片形式實施，例如但不限於，一個或複數個單核處理器、一個或複數個多核處理器或一個或複數個CISC處理器。

在一方面，處理器512和處理器522中之每一個可以以一個或複數個單核處理器、一個或複數個多核處理器或一個或複數個CISC處理器之形式實施。也就是說，即使本文中使用單數術語「處理器」指代處理器512和處理器522，然而依據本發明所述，處理器512和處理器522中之每一個在一些實施方式中可以包含複數個處理器，在其他實施方式中可以包含單個處理器。在另一方面，處理器512和處理器522中之每一個可以以具有電子組件之硬體（以及，可選地，韌體）形式實施，電子組件可以包含但不限於依據本發明所述特定目的配置和佈置之一個或複數個電晶體、一個或複數個二極體、一個或複數個電容器、一個或複數個電阻、一個或複數個電感、一個或複數個憶阻器和/或一個或複數個變容器。換句話說，依據本發明所述各個實施方式，至少在一些實施方式中，為了執行包含用於減少信令負荷和改善系統性能之無線通訊中條件式RRC確認訊息傳遞在內之特定任務，處理器512和處理器522中之每一個可以作為專門設計、配置和佈置之專用機。

在一些實施方式中，裝置510還可以包含收發器516，收發器516耦接於處理器512以及用於無線發送和接收資料。在一些實施方式中，裝置510也可以包含記憶體514，記憶體514耦接於處理器512以及可被處理器512存取並且在其中儲存資料。在一些實施方式中，裝置520亦可包含收發器526，收發器526耦接於處理器522以及用於無線發送和接收資料。在一些實施方式中，裝置520可以進一步包含記憶體524，記憶體524耦接於處理器522以及可被處理器522存取並且在其中儲存資料。因此，裝置510和裝置520可以分別透過收發器516和收發器526彼此進行無線通訊。

為了有助於更好地理解，在行動通訊環境之上下文中提供對裝置510和裝置520中每一個之操作、功能和能力之下文描述，以及在所述行動通訊環境中裝置510在無線通訊設備、通訊裝置或UE中實施或作為無線通訊設備、通訊裝置或UE實施，以及裝置520在連接到或否則通訊地耦接於MME 530之網路節點中實施或作為連接到或否則通訊地耦接於MME 530之網路節點實施。

依據本發明在所提出的關於條件式RRC確認訊息傳遞之方案下，作為UE之裝置510之處理器512可以經由收發器516與作為網路節點之網路裝置520通訊。在與網路裝置520通訊時，處理器512可以經由收發器516向網路裝置520發送第一訊息。此外，處理器512可以經由收發器516從裝置520接收第二訊息，以回應於發送該第一訊息。此外，處理器512可以確定是否向網路裝置520發送第三訊息，以確認接收該第二訊息。

在一些實施方式中，處理器512可以經由收發器512發送包含確認接收該第二訊息之確認訊息之該第三訊息，以回應於該確定之結果，其中該確定指示該第二訊息中之請求IE或者格式。在一些實施方式中，在發送第三訊息時，處理器512可以發送該第三訊息，進一步回應於該確定之該結果，其中該確定還指示除了確認訊息之外，在第一訊息中沒有足夠之空間來攜帶請求IE中請求之一條資訊。

在一些實施方式中，處理器512可以經由收發器512發送包含確認接收該第二訊息之確認訊息之該第三訊息，以回應於確定指示向網路裝置520進行UL傳輸之需求之結果。在一些實施方式中，在發送第三訊息時，處理器512可以發送該第三訊息，進一步回應於該確定之結果，其中該確定還指示除了該確認訊息之外在第三訊息中存在足夠之空間來攜帶資料、更高層信令或兩者。或者，在發送第三訊息時，處理器512可以發送第三訊息，以回應於該確定之結果，該確定指示UL傳輸之該需求，因為UE連接到連接到無線網路之不同之部分之另一網路節點。

在一些實施方式中，處理器512可以經由收發器512發送第三訊息，該第三訊息包含確認接收該第二訊息之確認訊息，以回應於確定指示有必要發送該第三訊息之結果。在一些實施方式中，第一訊息可以包含RRC連接請求訊息，第二訊息可以包含RRC連接建立訊息，並且第三訊息可以包含RRC連接建立完成訊息。

在一些實施方式中，第一訊息可以包含RRC連接恢復請求訊息，第二訊息可以包含RRC連接恢復訊息，並且第三訊息可以包含RRC連接恢復完成訊息。

在一些實施方式中，第一訊息可以包含RRC連接恢復請求訊息，第二訊息可以包含RRC連接建立訊息，並且第三訊息可以包含RRC連接建立完成訊息。

在一些實施方式中，第一訊息可以包含RRC連接早期資料請求訊息，並且第二訊息可以包含RRC早期資料完成訊息。

在一些實施方式中，第一訊息可以包含RRC連接恢復請求訊息加上行鏈路資料，並且其中第二訊息可以包含RRC連接釋放訊息。

在一些實施方式中，第一訊息可以包含RRC早期資料請求訊息，第二訊息可以包含RRC連接建立訊息，並且第三訊息可以包含RRC連接建立完成訊息。

在一些實施方式中，第一訊息可以包含RRC連接恢復請求訊息加上行鏈路資料，第二訊息可以包含RRC連接恢復訊息，並且第三訊息可以包含RRC連接恢復完成訊息。
說明性流程

第6圖係依據本發明之實施方式描述了示例流程600。流程600係上文所述關於用於減少信令負荷以及改善系統性能之無線通訊中之條件式RRC確認訊息所提出之方案之示例實施方式。流程600可以代表裝置510和裝置520之特征之實施方式之一方面。流程600可以包含區塊610、620、630和640中之一個或複數個所示之一個或複數個操作、動作或功能。雖然所示之各個區塊係離散的，然而依據所期望之實施方式，流程600中各個區塊可以拆分成更多區塊、組合成更少區塊或者刪除部分區塊。此外，流程600之區塊可以按照第6圖所示順序執行也可以以其他順序執行。流程600可以由裝置510、裝置520或任何合適之無線通訊設備、UE、基地台或機器型設備實施。在作為UE之裝置510以及作為無線網路（例如，5G/NR移動網路）之網路節點（例如，諸如gNB之基地台）之裝置520之內容中所描述之流程600僅出於說明目的並不具有限制性。流程600可以在區塊610處開始。

在610中，流程600可以包含裝置510之處理器512與作為網路節點之網路裝置520通訊。在與網路裝置520通訊時，流程600可以包含處理器512執行區塊620、630和640所示之複數個運作，流程600從610執行到620。

在620中，流程600可以包含處理器512經由收發器516向網路裝置520發送第一訊息。流程600從620執行到630。

在630中，流程600可以包含處理器512經由收發器516從裝置520接收第二訊息，以回應於發送該第一訊息。流程600從630執行到640。

在640中，流程600可以包含處理器512確定是否向網路裝置520發送第三訊息，以確認接收該第二訊息。

在一些實施方式中，流程600可以包含處理器512經由收發器512發送包含確認接收該第二訊息之確認訊息之該第三訊息，以回應於該確定之結果，其中該確定指示第二訊息中之請求IE或者格式。在一些實施方式中，在發送第三訊息時，流程600可以包含處理器512發送該第三訊息，進一步回應於該確定之該結果，其中該確定還指示除了該確認訊息之外，在第一訊息中沒有足夠之空間來攜帶請求IE中請求之一條資訊。

在一些實施方式中，流程600可以包含處理器512經由收發器512發送包含確認接收該第二訊息之確認訊息之該第三訊息，以回應於確定指示向網路裝置520進行UL傳輸之需求之結果。在一些實施方式中，在發送第三訊息時，流程600可以包含處理器512發送該第三訊息，進一步回應於該確定之結果，其中該確定還指示除了該確認訊息之外，在第三訊息中存在足夠之空間來攜帶資料、更高層信令或兩者。或者，在發送第三訊息時，流程600可以包含處理器512發送第三訊息，以回應於該確定之結果，該確定指示UL傳輸之該需求，因為UE連接到連接到無線網路之不同之部分之另一網路節點。

在一些實施方式中，流程600可以進一步包含處理器512經由收發器512發送包含確認接收該第二訊息之確認訊息之該第三訊息，以回應於確定指示有必要發送該第三訊息之結果。在一些實施方式中，第一訊息可以包含RRC連接請求訊息，第二訊息可以包含RRC連接建立訊息，並且第三訊息可以包含RRC連接建立完成訊息。

在一些實施方式中，第一訊息可以包含RRC連接恢復請求訊息加上行鏈路資料，第二訊息可以包含RRC連接恢復訊息，並且第三訊息可以包含RRC連接恢復完成訊息。
補充說明

本說明書中描述之主題有時描述包含在不同之其它組件內，或與其相連接之不同組件。但應當理解，這樣描繪之架構僅僅係示例，並且實際上可以實施完成相同功能之許多其它架構。在概念意義上，實現相同功能之組件之任何佈置被有效地「關聯」，使得實現期望之功能。因此，本文中被組合以實現特定功能之任何兩個組件可以被看作彼此「相關聯」，使得實現期望之功能，而不考慮架構或中間組件。同樣地，能夠如此關聯之任意兩個組件也可以被視為彼此「可操作地連接」，或「可操作地耦接」，以實現期望之功能，並且能夠如此關聯之任何兩個組件也可以被視為彼此「可操作地可耦接」，以實現期望之功能。可操作地可耦接之具體示例包含但不限於物理可配對及/或物理交互組件及/或無線交互及/或無線交互組件及/或邏輯交互及/或邏輯交互組件。

此外，針對在此實質上使用之任何複數和/或單數術語之使用，所屬領域具有通常知識者可以針對上下文和/或應用在適當時候從複數轉換為單數和/或從單數轉換為複數。為清楚起見可在本文明確闡述各種單數/複數置換。

此外，所屬領域具有通常知識者可以理解，通常本文所使用之術語，特別是在所附之申請專利範圍（例如所附申請專利範圍之主體）中使用之術語，一般旨在作為「開放式」術語，例如術語「包含」應被解釋為「包含但不限於」，術語「具有」應該被解釋為「至少具有」，術語「包含」應被解釋為「包含但不限於」等。所屬領域具有通常知識者可以進一步理解，如果意指所引入申請專利範圍列舉之具體數量，這樣之意圖將被明確列舉在申請專利範圍中，以及，缺少這樣之列舉時，不存在這樣之意圖。例如，為了有助於理解，所附申請專利範圍可包含引導性短語「至少一個」和「一個或複數個」之使用以來引入申請專利範圍列舉。然而，使用這樣之短語不應被解釋為暗示透過不定冠詞「一」或「一個」之申請專利範圍列舉之引入將含有這樣引入申請專利範圍列舉之任何特定申請專利範圍限制於只包含一個這樣之列舉，即使當相同申請專利範圍包含了引導性短語「一個或複數個」或「至少一個」和不定冠詞例如「一」或「一個」，例如「一」和/或「一個」應被解釋為是指「至少一個」或「一個或複數個」，這同樣適用於用來引入申請專利範圍列舉之定冠詞使用。此外，即使明確記載具體數量之所引入申請專利範圍要素，所屬領域具有通常知識者將認識到，這樣之陳述應被解釋為意指至少所列舉之數量，例如沒有其它修飾詞之敘述「兩個列舉」，是指至少兩個列舉或者兩個或更多列舉。此外，在使用類似於「A，B和C等中至少一個」之情況下，就其目的而言，通常這樣之結構希望所屬領域具有通常知識者將理解該慣例，例如「系統具有A，B和C中至少一個」將包含但不限於系統具有單獨的A、單獨的B、單獨的C、A和B一起、A和C一起、B和C一起、和/或A、B和C一起等。在使用類似於「A，B或C等中至少一個」之情況下，就其目的而言，通常這樣之結構，所屬領域具有通常知識者將理解該慣例，例如「系統具有A，B或C中至少一個」將包含但不限於系統具有單獨的A、單獨的B、單獨的C、A和B一起、A和C一起、B和C一起、和/或A、B和C一起等。所屬領域具有通常知識者將進一步理解，實際上表示兩個或複數個可選項之任何轉折詞語和/或短語，無論在說明書、申請專利範圍或圖式中，應該被理解為考慮包含複數個術語之一、任一術語、或兩個術語之可能性。例如，短語「A或B」將被理解為包含「A」或「B」或「A和B」之可能性。

由上可知，可以理解的是，出於說明目的本文已經描述了本發明之各種實施方式，並且在不脫離本發明之範圍和精神情況下可以做出各種修改。因此，本文所公開之各種實施方式並不意味著係限制性的，真正範圍和精神由所附申請專利範圍確定。

100、200A、200B、300、400A、400B‧‧‧場景

110、210、310、410‧‧‧使用者設備

120、220、320、420‧‧‧基地台

430、530‧‧‧行動管理實體

440‧‧‧服務閘道器

500‧‧‧示例通訊環境

510、520‧‧‧裝置

512、522‧‧‧處理器

514、524‧‧‧記憶體

516、526‧‧‧收發器

600‧‧‧流程

610、620、630、640‧‧‧區塊

所包含之附圖用以提供對本發明之進一步理解，以及，被併入並構成本發明一部分。圖式示出了本發明之實施方式，並與說明書一起解釋本發明之原理。可以理解的是，為了清楚地說明本發明之概念，圖式不一定按比例繪製，所示出的一些組件可以以超出與實際實施方式中之尺寸之比例示出。

第1圖係三向握手進程之示例場景之示意圖。

第2A圖係建立用於控制平面（control plane，CP）蜂巢式IoT（cellular IoT，CIoT）演進分封系統（Evolved Packet System，EPS）優化之RRC連接之示例場景之示意圖。

第2B圖建立用於使用者平面（user plane，UP）CIoT EPS優化之RRC連接之示例場景之示意圖。

第3圖係依據本發明之實施方式之雙向握手進程之示例場景之示意圖。

第4A圖係依據本發明之實施方式之用於CP CIoT EPS優化之示例早期資料發送進程之示意圖。

第4B圖係依據本發明之實施方式之用於UP CIoT EPS優化之示例早期資料發送進程之示意圖。

第5圖係依據本發明之實施方式之示例通訊環境之區塊圖。

第6圖係依據本發明之實施方式之示例流程之流程圖。

Claims

一種方法，其包含：由一使用者設備（UE）之處理器與一無線網路之一網路節點通訊，該通訊包含：由該處理器向該網路節點發送一第一訊息；由該處理器從該網路節點接收一第二訊息，以回應於發送該第一訊息；以及由該處理器確定是否向該網路節點發送一第三訊息，以確認接收該第二訊息。
如申請專利範圍第1項所述之方法，其中，進一步包含：由該處理器發送該第三訊息，該第三訊息包含一確認訊息，用以確認該第二訊息之接收，以回應於該確定之結果，該確定指示該第二訊息中之一請求資訊元素（IE）或一格式。
如申請專利範圍第2項所述之方法，其中，該第三訊息之該發送包含發送該第三訊息，以進一步回應於該確定之該結果，其中該確定還指示除了該確認訊息之外，在該第一訊息中沒有足夠之空間來攜帶該請求資訊元素中請求之一條資訊。
如申請專利範圍第1項所述之方法，其中，進一步包含：由該處理器發送該第三訊息，其中該第三訊息包含確認接收該第二訊息之一確認訊息，以回應於該確定之一結果，該確定指示向該網路節點進行一上行鏈路（UL）傳輸之一需求。
如申請專利範圍第4項所述之方法，其中，該第三訊息之該發送包含發送該第三訊息，以進一步回應於該確定之該結果，該確定還指示，除了該確認訊息之外，在該第三訊息中存在足夠之空間攜帶資料、更高層信令、或該資料和該更高層信令兩者。
如申請專利範圍第4項所述之方法，其中，該第三訊息之該發送包含發送該第三訊息，以進一步回應於該確定之該結果，該確定指示進行該上行鏈路傳輸之需求，因為該使用者設備連接到連接到該無線網路之一不同之部分之另一網路節點。
如申請專利範圍第1項所述之方法，其中，進一步包含：由該處理器發送該第三訊息，該第三訊息包含一確認訊息，用以確認該第二訊息之接收，以回應於該確定之一結果，其中該確定指示有必要發送該第三訊息。
如申請專利範圍第7項所述之方法，其中，該第一訊息包含無線電資源控制（RRC）連接請求訊息，其中該第二訊息包含無線電資源控制連接建立訊息，並且其中該第三訊息包含無線電資源控制連接建立完成訊息。
如申請專利範圍第7項所述之方法，其中，該第一訊息包含無線電資源控制（RRC）連接恢復請求訊息，其中該第二訊息包含無線電資源控制連接恢復訊息，並且其中該第三訊息包含無線電資源控制連接恢復完成訊息。
如申請專利範圍第7項所述之方法，其中，該第一訊息包含無線電資源控制（RRC）連接恢復請求訊息，其中該第二訊息包含無線電資源控制連接建立訊息，並且該其中第三訊息包含無線電資源控制連接建立完成訊息。
如申請專利範圍第7項所述之方法，其中，該第一訊息包含無線電資源控制（RRC）早期資料請求訊息，其中該第二訊息包含無線電資源控制連接建立訊息，並且其中該第三訊息包含無線電資源控制連接建立完成訊息。
如申請專利範圍第7項所述之方法，其中，該第一訊息包含無線電資源控制（RRC）連接恢復請求訊息加上行鏈路資料，其中該第二訊息包含無線電資源控制連接恢復訊息，並且其中該第三訊息包含無線電資源控制連接恢復完成訊息。
如申請專利範圍第1項所述之方法，其中，該第一訊息包含無線電資源控制（RRC）早期資料請求訊息，並且其中該第二訊息包含無線電資源控制早期資料完成訊息。
如申請專利範圍第1項所述之方法，其中，該第一訊息包含無線電資源控制（RRC）連接恢復請求訊息加上行鏈路資料，並且其中該第二訊息包含無線電資源控制連接釋放訊息。
一種裝置，其包含：一收發器，用以與一無線網路中一網路節點進行無線通訊；以及一處理器，耦接於該收發器，該處理器用於：經由該收發器向該網路節點發送一第一訊息；經由該收發器從該網路節點接收一第二訊息，以回應於發送該第一訊息；以及確定是否向該網路節點發送一第三訊息，以確認接收該第二訊息。