CN111989981A - 在cp-up分离中保持连接时丢弃缓冲数据的方法和设备 - Google Patents

在cp-up分离中保持连接时丢弃缓冲数据的方法和设备 Download PDF

Info

Publication number
CN111989981A
CN111989981A CN201980024702.4A CN201980024702A CN111989981A CN 111989981 A CN111989981 A CN 111989981A CN 201980024702 A CN201980024702 A CN 201980024702A CN 111989981 A CN111989981 A CN 111989981A
Authority
CN
China
Prior art keywords
gnb
message
rrc
data
last serving
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201980024702.4A
Other languages
English (en)
Other versions
CN111989981B (zh
Inventor
金鉐中
徐健
边大旭
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
LG Electronics Inc
Original Assignee
LG Electronics Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by LG Electronics Inc filed Critical LG Electronics Inc
Publication of CN111989981A publication Critical patent/CN111989981A/zh
Application granted granted Critical
Publication of CN111989981B publication Critical patent/CN111989981B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/19—Connection re-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W68/00—User notification, e.g. alerting and paging, for incoming communication, change of service or the like
    • H04W68/005—Transmission of information for alerting of incoming communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/27—Transitions between radio resource control [RRC] states
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/30—Connection release
    • H04W76/34—Selective release of ongoing connections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/02—Data link layer protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/02—Buffering or recovering information during reselection ; Modification of the traffic flow during hand-off

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

描述了一种用于在无线通信***中丢弃缓冲数据的方法和设备。gNB的中央单元(CU)用户平面(UP)从gNB的CU控制平面(CU‑CP)接收缓冲数据丢弃指示，并基于缓冲数据丢弃指示丢弃用户设备(UE)的缓冲数据。即使在丢弃缓冲数据之后，UE上下文仍然保留。CU‑CP是构成gNB的托管无线电资源控制(RRC)协议和分组数据汇聚协议(PDCP)‑C协议的逻辑节点，并且CU‑UP是构成gNB的托管PDCP‑U协议的逻辑节点。

Description

在CP-UP分离中保持连接时丢弃缓冲数据的方法和设备
技术领域
本发明涉及无线通信，并且更具体地，涉及在新的无线电接入技术(NR)***中当中央单元(CU)-控制平面(CP)和CU-用户平面(UP)分离时在保持连接的同时丢弃缓冲数据的方法和设备。
背景技术
第3代合作伙伴计划(3GPP)长期演进(LTE)是一种允许高速分组通信的技术。为了LTE目标已提出了许多方案，包括旨在降低用户和供应商成本、改进服务质量、以及扩展和改进覆盖和***容量的那些方案。作为上层要求，3GPP LTE需要降低每比特成本、增加服务可用性、灵活使用频带、简单结构、开放接口以及终端的适当功耗。
国际电信联盟(ITU)和3GPP已开始着手开发用于新无线电(NR)***的要求和规范。3GPP必须识别和开发将及时满足紧急市场需求和ITU无线电通信部门(ITU-R)国际移动电信(IMT)-2020进程所提出的更长期要求二者的新RAT成功标准化所需的技术组件。此外，NR应该能够使用即使在更遥远的未来也可用于无线通信的至少高达100GHz范围的任何频谱带。
NR的目标是应对所有使用场景、要求和部署场景的单个技术框架，包括增强移动宽带(eMBB)、大规模机器型通信(mMTC)、超可靠和低延迟通信(URLLC)等。NR应固有地向前兼容。
移动运营商正在变小的服务区域中提供更多服务。该小服务区域可以被指定为小小区。但是，这些小服务区域之间的通信传播可能是个问题，其中需要考虑容量、覆盖范围和干扰中的全部。因此，已经提出了通过集中式无线电接入网络(C-RAN)为小小区服务。实施C-RAN的一个要求是称为前传的新概念。
在NR中，将基站(例如，gNB)划分为中央单元(CU)和分布式单元(DU)以解决前传问题已被引入。另外，为了实现云RAN的概念，将CU划分为CU控制平面(CP)和CU用户平面(UP)已被引入。
发明内容
技术问题
当下一代无线电接入网络(NG-RAN)节点(例如gNB)仅具有待决用户平面数据要发送并且RAN发起的寻呼失败时，NG-RAN节点可以在NG-RAN节点中基于本地配置发起接入网释放过程或保持NG连接活动。在CP-UP分离中，尚未确定NG-RAN节点中的哪个节点/实体决定RAN寻呼失败的后续步骤。
技术方案
在一方面，提供了一种由无线通信***中的gNB的中央单元(CU)用户平面(UP)执行的方法。该方法包括：从gNB的CU控制平面(CU-CP)接收缓冲数据丢弃指示；以及基于该缓冲数据丢弃指示丢弃用户设备(UE)的缓冲数据。CU-CP是构成gNB的托管无线电资源控制(RRC)协议和分组数据汇聚协议(PDCP)-C协议的逻辑节点，并且CU-UP是构成gNB的托管PDCP-U协议的逻辑节点。
在另一方面，提供了一种无线通信***中的gNB的中央单元(CU)用户平面(UP)。CU-CP被配置为从gNB的CU控制平面(CU-CP)接收缓冲数据丢弃指示，并基于缓冲数据丢弃指示丢弃用户设备(UE)的缓冲数据。CU-CP是构成gNB的托管无线电资源控制(RRC)协议和分组数据汇聚协议(PDCP)-C协议的逻辑节点，并且CU-UP是构成gNB的托管PDCP-U协议的逻辑节点。
技术效果
首先，对于RAN寻呼失败，CU-CP或CU-UP可以有效地控制是保持NG连接活动，还是释放NG连接并删除存储的UE上下文。CU-CP或CU-UP可以在保持NG连接的同时丢弃缓冲数据。
其次，CU-CP可以有效地控制CU-UP或DU是否将缓冲的DL数据转发给UE。因此，由于可以避免DL数据的丢失并且可以减少由于数据重传导致的不必要的时延，因此可以增强UE的体验。
附图说明
图1示出了可以应用本发明的技术特征的无线通信***的示例。
图2示出了NG-RAN的总体架构的示例。
图3示出了逻辑gNB/en-gNB中的逻辑节点(CU-C，CU-U和DU)。
图4示出了gNB的部署方案。
图5示出了在gNB-CU-CP和gNB-CU-UP之间定义的E1接口的协议结构。
图6示出了根据本发明的实施方式1-1的由gNB-CU-UP执行的丢弃缓冲数据的方法。
图7示出了根据本发明的实施方式1-1的RAN寻呼失败的总体过程。
图8示出了根据本发明的实施方式1-1的考虑数据缓冲的E1设置过程。
图9示出了根据本发明的实施方式1-2的RAN寻呼失败的总体过程。
图10示出了根据本发明的实施方式2-1的总体过程。
图11示出了根据本发明的实施方式2-1的总体过程。
图12示出了根据本发明的实施方式2-2的总体过程。
图13示出了根据本发明的实施方式2-2的总体过程。
具体实施方式
下面所描述的技术特征可由第3代合作伙伴计划(3GPP)标准化组织的通信标准、电气和电子工程师协会(IEEE)的通信标准等使用。例如，3GPP标准化组织的通信标准包括长期演进(LTE)和/或LTE***的演进。LTE***的演进包括LTE-advanced(LTE-A)、LTE-APro和/或5G新无线电(NR)。IEEE标准化组织的通信标准包括诸如IEEE 802.11a/b/g/n/ac/ax的无线局域网(WLAN)***。上述***针对下行链路(DL)和/或上行链路(DL)使用诸如正交频分多址(OFDMA)和/或单载波频分多址(SC-FDMA)的各种多址技术。例如，仅OFDMA可用于DL并且仅SC-FDMA可用于UL。另选地，OFDMA和SC-FDMA可用于DL和/或UL。
在本文档中，术语“/”和“，”应解释为表示“和/或”。例如，表达“A/B”可以表示“A和/或B”。此外，“A，B”可以表示“A和/或B”。此外，“A/B/C”可以表示“A，B和/或C中的至少一个”。另外，“A，B，C”可以表示“A，B和/或C中的至少一个”。
此外，在文档中，术语“或”应解释为表示“和/或”。例如，表述“A或B”可包括1)仅A，2)仅B和/或3)A和B两者。换句话说，本文档中的术语“或”应解释为表示“另外地或另选地。”
图1示出了可以应用本发明的技术特征的无线通信***的示例。
具体地，图1示出了基于5G新无线电接入技术(NR)***的***架构。5G NR***(以下简称为“NR”)中使用的实体可以吸收LTE中引入的实体(例如eNodeB(eNB)，移动性管理实体(MME)，服务网关(S-GW)等)中的一些或全部。NR***中使用的实体可以通过名称“NG”来标识，以与LTE/LTE-A区分开。
参照图1，无线通信***包括一个或多个UE、下一代RAN(NG-RAN)和第五代核心网(5GC)。NG-RAN包括至少一个NG-RAN节点。NG-RAN节点包括至少一个gNB和/或至少一个ng-eNB。gNB向UE提供NR用户平面和控制平面协议终止。ng-eNB 22向UE提供E-UTRA用户平面和控制平面协议终止。
5GC包括接入和移动性管理功能(AMF)、用户平面功能(UPF)和会话管理功能(SMF)。AMF托管诸如NAS安全性、空闲状态移动性处理等的功能。AMF是包含常规MME的功能的实体。UPF托管诸如移动性锚定、协议数据单元(PDU)处理这样的功能。UPF是包括常规S-GW的功能的实体。SMF托管诸如UE IP地址分配、PDU会话控制这样的功能。
gNB和ng-eNB通过Xn接口彼此互连。gNB和ng-eNB也通过NG接口连接到5GC，更具体地说是通过NG-C接口连接到AMF，并通过NG-U接口连接到UPF。
gNB和/或ng-eNB托管以下功能：
-无线电资源管理功能：无线电承载控制，无线电接纳控制，连接移动性控制，在上行链路和下行链路(调度)中针对UE的资源动态分配；
-互联网协议(IP)报头压缩，数据的加密和完整性保护；
-当无法从由UE提供的信息中确定到AMF的路由时，在UE附着处选择AMF；
-将用户平面数据路由到UPF；
-将控制平面信息路由到AMF；
-连接建立和释放；
-调度和发送寻呼消息；
-(源自AMF或操作与维护(O&M)的)***广播信息的调度和发送；
-用于移动性和调度的测量和测量报告配置；
-上行链路中的传输级分组标记；
-会话管理；
-支持网络切片；
-QoS流管理并映射到数据无线电承载；
-支持处于RRC_INACTIVE状态的UE；
-非接入层(NAS)消息的分发功能；
-无线电接入网络共享；
-双连接；
-NR和E-UTRA之间紧密互通。
AMF托管以下主要功能：
-NAS信令终止；
-NAS信令安全性；
-AS安全性控制；
-用于3GPP接入网之间的移动性的CN间节点信令；
-空闲模式UE可达性(包括控制和寻呼重传的执行)；
-注册区管理；
-支持***内和***间的移动性；
-接入认证；
-接入授权，包括漫游权限检查；
-移动性管理控制(订阅和策略)；
-支持网络切片；
-SMF选择。
UPF托管以下主要功能：
-无线电接入技术(RAT)内/RAT间移动性的锚点(适用时)；
-与数据网络互连的外部协议数据单元(PDU)会话点；
-分组路由和转发；
-策略规则执行的分组检查和用户平面部分；
-流量使用情况报告；
-上行链路分类器，以支持将流量流路由到数据网络；
-支持多宿主PDU会话的分支点；
-用户平面的QoS处理，例如分组过滤、门控、UL/DL速率执行；
-上行链路流量验证(服务数据流(SDF)到QoS流映射)；
-下行链路分组缓冲和下行链路数据通知触发。
SMF托管以下主要功能：
-会话管理；
-UE IP地址分配和管理；
-UP功能的选择和控制；
-在UPF处配置流量控制，以将流量路由到合适的目的地；
-策略执行和QoS的控制部分；
-下行链路数据通知。
图2示出了NG-RAN的总体架构的示例。
参照图2，gNB可以包括gNB中央单元(CU)(在下文中，gNB-CU可以简称为CU)和至少一个gNB分布式单元(DU)(在下文中，gNB-DU可以简称为DU)。
gNB-CU是gNB的托管无线电资源控制(RRC)协议、服务数据适配协议(SDAP)和分组数据汇聚协议(PDCP)或en-gNB的RRC协议和PDCP协议的逻辑节点。gNB-CU控制至少一个gNB-DU的操作。
gNB-DU是gNB或en-gNB的托管无线电链路控制(RLC)、媒体访问控制(MAC)和物理层的逻辑节点。gNB-DU的操作部分地由gNB-CU控制。一个gNB-DU支持一个或多个小区。一个小区仅由一个gNB-DU支持。
gNB-CU和gNB-DU经由F1接口连接。gNB-CU终止连接到gNB-DU的F1接口。gNB-DU终止连接到gNB-CU的F1接口。一个gNB-DU仅连接到一个gNB-CU。然而，可以通过适当的实现将gNB-DU连接到多个gNB-CU。F1接口是逻辑接口。对于NG-RAN，包括gNB-CU和gNB-DU的gNB的NG和Xn-C接口终止于gNB-CU中。对于E-UTRAN-NR双连接(EN-DC)，包括gNB-CU和gNB-DU的gNB的S1-U和X2-C接口终止于gNB-CU中。gNB-CU和连接的gNB-DU对其它gNB和5GC仅作为gNB可见。
图3示出了逻辑gNB/en-gNB中的逻辑节点(CU-C，CU-U和DU)。图3示出了图2所示的NG-RAN的一种可能的部署方案。NG和Xn接口的协议终止在图3中由椭圆表示。在图3中，中央实体和分布式实体代表物理网络节点。
图4示出了gNB的部署方案。图4示出了图2和图3中所示的NG-RAN的架构和可能的部署方案的示例。
图4的(a)示出了收缩的gNB部署方案。在这种部署方案中，所有RAN协议和功能都位于同一位置。该部署方案与LTE中当前使用的方案相对应。该部署方案与LTE架构相似，从而确保了与现有LTE部署方案的最大向后兼容性。
图4的(b)示出了分解的部署方案。在此部署方案中，RAN协议功能分布在不同的位置，例如gNB-CU和gNB-DU。gNB-DU托管RLC层、MAC层和物理层。gNB-CU-CP(在下文中，gNB-CU-CP可以简称为CU-CP)托管RRC和PDCP-C协议。gNB-CU-UP(在下文中，gNB-CU-UP可以简称为CU-UP)托管PDCP-U(和SDAP)协议。
一个gNB可以包括一个gNB-CU-CP、多个gNB-CU-UP和多个gNB-DU。gNB-CU-CP通过F1-C接口连接到gNB-DU。gNB-CU-UP通过F1-U接口连接到gNB-DU。gNB-CU-UP通过E1接口连接到gNB-CU-CP。一个gNB-DU仅连接到一个gNB-CU-CP。一个gNB-CU-UP仅连接到一个gNB-CU-CP。然而，可以通过适当的实现将gNB-DU和/或gNB-CU-UP连接到多个gNB-CU-CP。一个gNB-DU可以在同一gNB-CU-CP的控制下连接到多个gNB-CU-UP。一个gNB-CU-UP可以在同一gNB-CU-CP的控制下连接到多个gNB-DU。由gNB-CU-CP使用承载上下文管理功能在gNB-CU-UP和gNB-DU之间建立连接。gNB-CU-CP为UE请求的服务选择适当的gNB-CU-UP。在多个gNB-CU-UP的情况下，它们属于同一安全性域。Xn-U可以支持gNB内的gNB-CU-CP内切换期间gNB-CU-UP之间的数据转发。
根据图4的(b)所示的分解部署方案，可以基于方案和期望的性能将RAN功能最佳地部署在不同的位置。例如，CU-CP可以位于DU附近。另选地，CU-CP可以与DU一起部署。在这种情况下，可以为重要的CP过程(例如连接(重新)建立，切换和状态转换)提供较短的时延时间。另一方面，CU-UP可以集中在区域或国家数据中心中。因此，CU-UP对于云实现是有利的，并且可以在双连接和紧密互通方案中为UP流量提供集中的终止点。此外，可以在DU附近(或与DU共位)放置额外的CU-UP，以为需要非常短的时延时间的应用(例如超可靠的低时延通信(URLLC)流量)提供UP流量的本地终止点。
图5示出了在gNB-CU-CP和gNB-CU-UP之间定义的E1接口的协议结构。传输网络层(TNL)基于互联网协议(IP)传输，并且包括在IP层上方的流控制传输协议(SCTP)层。应用层信令协议称为E1应用协议(E1AP)。
RRC不活动状态(RRC_INACTIVE)可以被表征如下。
-公共陆地移动网络(PLMN)选择；
-广播***信息；
-小区重选移动性；
-寻呼是由NG-RAN发起的(RAN寻呼)；
-基于RAN的通知区域(RNA)由NG-RAN管理；
-由NG-RAN配置的RAN寻呼的不连续接收(DRX)；
-为UE建立了5GC-NG-RAN连接(C/U平面二者)；
-UE接入层(AS)上下文存储在NG-RAN和UE中；
-NG-RAN知道UE所属的RNA。
描述了寻呼。处于RRC_IDLE和RRC_INACTIVE状态的UE可以使用DRX以便减少功耗。当处于RRC_IDLE时，UE针对核心网(CN)发起的寻呼信息监视寻呼控制信道(PCCH)。当处于RRC_INACTIVE时，UE针对RAN发起和CN发起的寻呼信息监视PCCH。NG-RAN和5GC寻呼时机重叠，并且在NG-RAN和5GC中使用相同的寻呼机制。UE针对寻呼的接收在每个DRX周期中监视一个寻呼时机如下：
-寻呼DRX周期长度是可配置的：
-可以经由***信息配置用于CN发起的寻呼的默认DRX周期；
-当处于RRC_IDLE时，可经由UE专用信令配置用于CN发起的寻呼的UE特定DRX周期。
-NG-RAN可以利用用于RAN发起的寻呼的DRX周期来配置UE。该配置可以是特定于UE的。
-可经由***信息配置DRX周期中的寻呼时机的数量：
-当在DRX周期中配置了多个寻呼时机时，网络可以基于UE id将UE分配给寻呼时机。
-寻呼时机可以包含多个时隙(例如子帧或OFDM符号)。寻呼时机中的时隙数量可经由***信息来配置。
-网络可以在每个时隙中使用不同的一组DL发送波束或重复来发送寻呼。
在NR中，对于CP-UP分离，有关gNB-CU-CP和gNB-CU-UP如何支持处于RRC_INACTIVE的UE的讨论正在进行中。具体而言，有可能上次服务gNB-CU-CP未从处于RRC_INACTIVE的UE收到寻呼响应。如果RAN寻呼过程未能成功建立与UE的联系，并且如果NG RAN仅具有待决用户平面数据要发送，则NG-RAN节点可以基于在NG-RAN中的本地配置发起接入网释放过程或保持NG连接活动。
在CP-UP分离中，尚未确定哪个节点/实体(即gNB-CU-CP或gNB-CU-UP)决定RAN寻呼失败的后续步骤。即，在DL数据的RAN寻呼失败的情况下，应在gNB-CU-CP或gNB-CU-UP中配置有关维持还是释放NG连接的信息。不管哪个节点/实体做出决定，都可以由传统过程来处理针对RAN寻呼失败的接入网释放过程的发起。但是，尚未讨论保持NG连接活动并丢弃针对RAN寻呼失败的缓冲DL数据的详细过程。由于gNB-CU-CP和gNB-CU-UP在CP-UP分离时可能位于不同的物理站点，因此应讨论如何保持NG连接活动并针对RAN寻呼失败丢弃缓冲DL数据。
1.实施方式1-1
根据本发明的实施方式1-1，当gNB-CU-CP检测到DL数据的RAN寻呼失败时，gNB-CU-CP可以决定是维持还是释放用于UE的NG连接。如果上次服务gNB-CU-CP决定保持NG连接活动，则gNB-CU-CP向gNB-CU-UP指示应丢弃已缓冲的DL数据并保持UE的承载上下文。即，当上次服务gNB-CU-CP能够决定保持NG连接活动并且仅丢弃缓冲的DL数据时，上次服务gNB-CU-CP向上次服务gNB-CU-UP指示立即丢弃缓冲的DL数据并存储与寻呼失败有关的UE上下文。这可以通过将与RAN寻呼失败相关的新指示添加到承载上下文修改请求消息中来解决。此指示使gNB-CU-UP能够仅丢弃UE的缓冲的DL数据并保留UE的承载上下文。
图6示出了根据本发明的实施方式1-1的由gNB-CU-UP执行的丢弃缓冲数据的方法。
在步骤S600中，gNB-CU-UP从gNB-CU-CP接收缓冲数据丢弃指示。在步骤S610中，gNB-CU-UP基于缓冲数据丢弃指示来丢弃用于UE的缓冲数据。CU-CP是构成gNB的托管RRC协议和PDCP-C协议的逻辑节点，并且CU-UP是构成gNB的托管PDCP-U协议的逻辑节点。
缓冲数据丢弃指示可以针对UE指示发生RAN寻呼失败。gNB-CU-UP可以保持存储UE的上下文。可以维持CU-UP和UPF之间的连接。可以维持CU-CP和AMF之间的连接。
可以经由承载上下文修改请求消息来发送缓冲数据丢弃指示。缓冲数据丢弃指示可以是承载上下文修改请求消息中的IE(例如，“需要数据丢弃”IE)。表1示出了承载上下文修改请求消息的示例。由gNB-CU-CP发送此消息，以请求gNB-CU-UP修改承载上下文。
[表1]
Figure BDA0002715490020000101
Figure BDA0002715490020000111
Figure BDA0002715490020000121
Figure BDA0002715490020000131
Figure BDA0002715490020000141
Figure BDA0002715490020000151
Figure BDA0002715490020000161
在表1中，承载上下文修改请求消息中的“需要数据丢弃”IE是缓冲数据丢弃指示。如果承载上下文修改请求消息中包含需要数据丢弃IE，并且该值被设置为“需要”，则gNB-CU-UP将丢弃该UE的用户平面数据，并认为承载上下文仍被挂起。
图7示出了根据本发明的实施方式1-1的RAN寻呼失败的总体过程。图7示出了当gNB-CU-CP决定保持NG连接活动并且丢弃缓冲的DL数据时用于RAN寻呼失败的过程。
UE处于RRC_INACTIVE。UE和上次服务gNB-CU存储UE上下文。上次服务gNB-CU-CP和AMF之间的NG-C连接被维持。另外，上次服务gNB-CU-UP和UPF之间的NG-U连接被维持。上次服务gNB-CU和gNB-DU之间的F1连接断开。
步骤S702：当上次服务gNB-CU-UP接收到与处于RRC_INACTIVE的UE相关的PDU会话的DL数据，并且针对PDU会话上次服务gNB-CU-UP中没有存储F1-DL隧道端点标识符(TEID)时，上次服务gNB-CU-UP缓冲DL数据。
步骤S704：在任何服务质量(QoS)流的第一个DL数据分组到达时，上次服务gNB-CU-UP应经由E1接口将下行链路数据通知消息发送到上次服务gNB-CU-CP。该消息可以包括用于标识DL数据分组的QoS流的信息，以便支持gNB中的寻呼策略区分特征。
步骤S705：当上次服务gNB-CU-CP检测到该UE对于寻呼暂时是不可达的时(例如，如果使用增强型DRX(eDRX)，或者该UE仅对于监管优先服务是可达的等)，则上次服务gNB-CU-CP经由E1接口将RAN寻呼延迟(PAGING DELAYED)消息发送到上次服务gNB-CU-UP。RAN寻呼延迟消息可能包含原因值IE和等待时间IE，以便请求扩展的缓冲。原因值IE用于指示下行链路数据通知消息已被暂时拒绝的原因。等待时间IE是在能够建立/恢复到UE的无线电承载之前的期望时间。
原因值IE和等待时间IE可以经由针对下行链路数据通知消息的响应消息发送到上次服务gNB-CU-UP。
步骤S706：在步骤S704中从上次服务gNB-CU-UP接收到下行链路数据通知消息后，上次服务gNB-CU-CP发起RAN寻呼以在基于RAN的通知区域中找到UE。如果由AMF配置了寻呼策略区分，则映射到用于在下行链路数据通知消息中标识DL数据分组的QoS流的信息的RAN寻呼优先级IE可以被包括在RAN寻呼消息中。
步骤S708：上次服务gNB-CU-CP经由Xn接口将RAN寻呼消息发送到同一基于RAN的通知区域中的相邻gNB。
步骤S710
Figure BDA0002715490020000171
步骤S712：同一基于RAN的通知区域中的各个gNB-CU经由F1接口将寻呼消息发送到gNB-DU。如果RAN寻呼优先级IE包含在RAN寻呼消息中，则gNB-CU-CP可以使用它来优先化寻呼。然后，每个gNB-DU将寻呼消息发送到UE。
步骤S714：如果上次服务gNB-CU-CP没有从UE接收到对寻呼消息的响应(例如，该过程的定时器到期等)，则上次服务gNB-CU-CP考虑该UE的RAN寻呼失败。基于本地配置，上次服务gNB-CU-CP可以保持NG连接活动或发起UE上下文释放请求过程。
步骤S716：当上次服务gNB-CU-CP决定保持NG连接活动时，上次服务gNB-CU-CP经由E1接口将缓冲数据丢弃指示发送到上次服务gNB-CU-UP。缓冲数据丢弃指示可以指示UE是不可达的。缓冲数据丢弃指示可以是E1AP消息BUFFERED DATA DISCARD(缓冲数据丢弃)。或者，缓冲数据丢弃指示可以是承载上下文修改请求消息中的IE。缓冲数据丢弃指示还可以用于指示上次服务gNB-CU-UP立即丢弃缓冲的DL数据并且继续存储与寻呼失败有关的UE上下文。
当上次服务gNB-CU-CP决定让UE进入RRC_IDLE时，上次服务gNB-CU-CP经由NG接口将UE上下文释放请求(CONTEXT RELEASE REQUEST)消息发送到AMF。此外，上次服务gNB-CU-CP通过经由E1接口向上次服务gNB-CU-UP发送承载上下文释放命令(BEARER CONTEXTRELEASE COMMAND)消息来触发承载上下文释放过程。在这种情况下，上次服务gNB-CU-UP删除UE上下文并丢弃缓冲的DL数据。在这种情况下，应跳过下面的步骤S718和S720。
步骤S718：在从上次服务gNB-CU-CP接收到缓冲数据丢弃指示后，上次服务gNB-CU-UP丢弃该UE的缓冲的DL数据。
步骤S720：UE仍处于RRC_INACTIVE。UE和上次服务gNB-CU保持存储UE上下文。因此，UE上下文仍然保持/挂起。上次服务gNB-CU-CP和AMF之间的NG-C连接被维持。另外，上次服务gNB-CU-UP和UPF之间的NG-U连接被维持。
根据图6和图7中描述的本发明的实施方式1-1，对于RAN寻呼失败，gNB-CU-CP可以有效地控制是保持NG连接活动而不删除存储的UE上下文，还是释放NG连接并删除存储的UE上下文。
图8示出了根据本发明的实施方式1-1的考虑数据缓冲的E1建立过程。
步骤S802：gNB-CU-UP通过经由E1接口向gNB-CU-CP发送包含适当数据的E1建立请求消息来发起该过程。E1建立请求消息可以包含用于指示与gNB-CU-UP中的数据缓冲有关的信息(例如，缓冲区大小，最大扩展缓冲时间等)的数据缓冲能力IE以及用于通知针对RAN寻呼失败如何通过操作和维护(OAM)来配置gNB-CU-UP(例如NG连接释放，数据丢弃等)的RAN寻呼失败IE。
步骤S804：gNB-CU-CP利用包含适当数据的E1建立响应消息进行响应。
可以经由E1接口通过gNB-CU-CP触发的和gNB-CU-UP触发的配置更新过程将数据缓冲能力IE和RAN寻呼失败IE的配置传递到gNB-CU-CP。
2.实施方式1-2
根据本发明的实施方式1-2，当上次服务gNB-CU-UP能够决定保持NG连接活动并且仅丢弃缓冲的DL数据时，上次服务gNB-CU-CP仅通知上次服务gNB-CU-UP RAN寻呼失败。上次服务gNB-CU-UP基于RAN寻呼失败指示确定丢弃缓冲的DL数据，然后向上次服务gNB-CU-CP指示缓冲的DL数据被丢弃并且UE上下文仍然保留。
图9示出了根据本发明的实施方式1-2的RAN寻呼失败的总体过程。图9示出了当gNB-CU-UP决定保持NG连接活动并且丢弃缓冲的DL数据时用于RAN寻呼失败的过程。
UE处于RRC_INACTIVE。UE和上次服务gNB-CU存储UE上下文。上次服务gNB-CU-CP和AMF之间的NG-C连接被维持。另外，上次服务gNB-CU-UP和UPF之间的NG-U连接被维持。上次服务gNB-CU和gNB-DU之间的F1连接断开。
步骤S902：当上次服务gNB-CU-UP接收到与处于RRC_INACTIVE的UE相关的PDU会话的DL数据，并且针对PDU会话上次服务gNB-CU-UP中没有存储F1-DL TEID时，上次服务gNB-CU-UP缓冲DL数据。
步骤S904：在任何QoS流的第一个DL数据分组到达时，上次服务gNB-CU-UP将经由E1接口向上次服务gNB-CU-CP发送下行链路数据通知消息。该消息可以包括用于标识DL数据分组的QoS流的信息，以便支持gNB中的寻呼策略区分特征。
步骤S905：当上次服务gNB-CU-CP检测到该UE对于寻呼暂时是不可达的时(例如，如果使用eDRX，或者该UE仅对于监管优先服务而言是可达的，等等)，则上次服务gNB-CU-CP经由E1接口将RAN寻呼延迟消息发送到上次服务gNB-CU-UP。RAN寻呼延迟消息可以包含原因值IE和等待时间IE，以便请求扩展的缓冲。原因值IE用于指示下行链路数据通知消息被暂时拒绝的原因。等待时间IE是在能够建立/恢复到UE的无线电承载之前的期望时间。
原因值IE和等待时间IE可以经由针对下行链路数据通知消息的响应消息发送到上次服务gNB-CU-UP。
步骤S906：在步骤S904中从上次服务gNB-CU-UP接收到下行链路数据通知消息后，上次服务gNB-CU-CP发起RAN寻呼以在基于RAN的通知区域中找到UE。如果由AMF配置了寻呼策略区分，则映射到用于在下行链路数据通知消息中标识DL数据分组的QoS流的信息的RAN寻呼优先级IE可以被包括在RAN寻呼消息中。
步骤S908：上次服务gNB-CU-CP经由Xn接口将RAN寻呼消息发送到同一基于RAN的通知区域中的相邻gNB。
步骤S910
Figure BDA0002715490020000191
S912：同一基于RAN的通知区域中的各个gNB-CU经由F1接口将寻呼消息发送到gNB-DU。如果RAN寻呼优先级IE包含在RAN寻呼消息中，则gNB-CU-CP可以使用它来优先化寻呼。然后，每个gNB-DU将寻呼消息发送到UE。
步骤S914：如果上次服务gNB-CU-CP没有从UE接收到针对寻呼消息的响应(例如，该过程的定时器到期等)，则上次服务gNB-CU-CP考虑该UE的RAN寻呼失败。
步骤S916：然后，上次服务gNB-CU-CP经由E1接口将RAN寻呼失败通知消息发送到上次服务gNB-CU-UP，以指示UE是不可达的。
步骤S918：在从上次服务gNB-CU-CP接收到RAN寻呼失败通知消息后，基于本地配置，上次服务gNB-CU-UP可以保持NG连接活动或者发起UE上下文请求释放过程。当上次服务gNB-CU-UP决定保持NG连接活动时，上次服务gNB-CU-UP仅丢弃该UE的缓冲的DL数据。
当上次服务gNB-CU-UP决定让UE进入RRC_IDLE时，上次服务gNB-CU-UP触发承载上下文释放请求过程，以向上次服务gNB-CU-CP请求释放该UE的挂起的无线电承载(RB)。在这种情况下，应跳过下面的步骤S920和S922。
步骤S920：当上次服务gNB-CU-UP决定保持NG连接活动时，上次服务gNB-CU-UP经由E1接口可以数据丢弃通知消息进行响应，以指示已缓冲的DL数据被丢弃并且UE上下文仍然保留。
步骤S922：UE仍处于RRC_INACTIVE状态。UE和上次服务gNB-CU保持存储UE上下文。因此，UE上下文仍然保持/挂起。上次服务gNB-CU-CP和AMF之间的NG-C连接被维持。另外，上次服务gNB-CU-UP和UPF之间的NG-U连接被维持。
根据图9中描述的本发明的实施方式1-2，对于RAN寻呼失败，gNB-CU-UP可以有效地控制是保持NG连接活动而不删除存储的UE上下文，还是释放NG连接并删除存储的UE上下文。然而，与上述本发明的实施方式1-1相比，可能需要附加的E1AP信令。
此外，当UE针对移动终端(MT)数据从RRC_INACTIVE转变为RRC_CONNECTED时，可能存在问题。当存在发送到UE的DL数据时，存储UE上下文的上次服务gNB-CU可以在基于RAN的通知区域中触发RAN发起的寻呼，以便与UE联系。在接收到寻呼消息后，UE针对寻呼来对gNB进行响应。然后，gNB-CU-CP发起用于恢复挂起的RB的过程，以发送UE的MT数据。在此过程中，由于RRC和PDCP-C被托管在gNB-CU-CP处，因此gNB-CU-UP不知道UE的实际RRC状态。此外，在没有来自gNB-CU-CP的通知的情况下，gNB-CU-UP很难知道RRC恢复消息被发送给UE的时间。因此，gNB-CU-UP在被告知F1-DL TEID时就开始向UE转发MT数据。然而，仅当UE通过从gNB-CU-CP接收到RRC恢复消息进入RRC_CONNECTED时UE才能够接收DL数据。如果在从RRC_INACTIVE到RRC_CONNECTED的RRC状态转换完成之前DL数据到达UE，则到达的DL数据只是被丢弃，从而导致来自NGC的不必要的数据重传。
因此，应该讨论gNB-CU-CP如何通知gNB-CU-UP开始向UE转发MT数据的时间。根据本发明，可以提出一种用于有效地根据用于MT数据的RAN发起的寻呼的成功或失败来支持从RRC_INACTIVE到RRC_CONNECTED或RRC_IDLE的UE状态转换的方法。
3.实施方式2-1
根据本发明的实施方式2-1，gNB-CU-CP防止gNB-CU-UP向UE转发缓冲的DL数据。当gNB-CU-CP知道UE的到RRC_CONNECTED的成功状态转换时，gNB-CU-CP通知gNB-CU-UP被允许向UE发送缓冲的DL数据。对于UE对于寻呼暂时是不可达的情况，gNB-CU-CP还可以向gNB-CU-UP指示需要扩展的缓冲。
图10示出了根据本发明的实施方式2-1的总体过程。图10示出了当UE接入上次服务gNB时在gNB-CU-UP中具有DL数据缓冲的成功RRC连接恢复的过程的第一部分。
UE处于RRC_INACTIVE。UE和上次服务gNB-CU存储UE上下文。上次服务gNB-CU-CP和AMF之间的NG-C连接被维持。另外，上次服务gNB-CU-UP和UPF之间的NG-U连接被维持。上次服务gNB-CU和gNB-DU之间的F1连接断开。
步骤S1002：当上次服务gNB-CU-UP接收到与处于RRC_INACTIVE的UE相关的PDU会话的DL数据，并且针对PDU会话上次服务gNB-CU-UP中没有存储F1-DL TEID时，上次服务gNB-CU-UP缓冲DL数据。
步骤S1004：在任何QoS流的第一个DL分组到达时，上次服务gNB-CU-UP将经由E1接口向上次服务gNB-CU-CP发送下行链路数据通知消息。该消息可以包括用于标识DL数据分组的QoS流的信息，以便支持gNB中的寻呼策略区分特征。
步骤S1005：当上次服务gNB-CU-CP检测到该UE对于寻呼暂时是不可达的时(例如，使用eDRX，或者该UE仅对于监管优先服务是可达的等)，上次服务gNB-CU-CP经由E1接口将RAN寻呼延迟消息发送到上次服务gNB-CU-UP。RAN寻呼延迟消息可以包含原因值IE和等待时间IE，以便请求扩展的缓冲。原因值IE用于指示下行链路数据通知消息被暂时拒绝的原因。等待时间IE是在能够建立/恢复到UE的无线电承载之前的期望时间。
原因值IE和等待时间IE可以经由针对下行链路数据通知消息的响应消息发送到上次服务gNB-CU-UP。
步骤S1006：在步骤S1004中从上次服务gNB-CU-UP接收到下行链路数据通知消息后，上次服务gNB-CU-CP发起RAN寻呼以在基于RAN的通知区域中找到UE。如果由AMF配置了寻呼策略区分，则映射到用于在下行链路数据通知消息中标识DL数据分组的QoS流的信息的RAN寻呼优先级IE可以被包括在RAN寻呼消息中。
步骤S1008：上次服务gNB-CU-CP经由Xn接口将RAN寻呼消息发送到同一基于RAN的通知区域中的相邻gNB。
步骤S1010
Figure BDA0002715490020000221
S1012：同一基于RAN的通知区域中的各个gNB-CU经由F1接口将寻呼消息发送到gNB-DU。如果RAN寻呼优先级IE包含在RAN寻呼消息中，则gNB-CU-CP可以使用它来优先化寻呼。然后，各个gNB-DU将寻呼消息发送到UE。在这种情况下，上次服务gNB-DU发送的寻呼消息到达UE。
步骤S1014：由于处于RRC_INACTIVE的UE需要转换到RRC_CONNECTED，因此UE首先将随机接入前导码或新消息发送到gNB-DU。
步骤S1016：在从UE接收到随机接入前导码后，gNB-DU随后利用随机接入响应进行响应。
步骤S1018：为了恢复RRC连接，UE将RRC恢复请求消息(或新消息)发送到gNB-DU。RRC恢复请求消息还包括用于在上次服务gNB-CU中识别UE上下文的不活动无线电网络临时标识符(I-RNTI)。
步骤S1020：在接收到RRC恢复请求消息(或新消息)后，gNB-DU经由F1接口将初始上行链路RRC消息传送消息(或新消息)发送到上次服务gNB-CU-CP。初始上行链路RRC消息传送消息可以包括捎带RRC恢复请求消息的容器。
步骤S1022：在接收到包括用于包括I-RNTI的RRC恢复请求消息的容器的初始上行链路RRC消息传送消息后，上次服务gNB-CU-CP检查是否能够找到与I-RNTI有关的UE上下文。
图11示出了根据本发明的实施方式2-1的总体过程。图11示出了当UE接入上次服务gNB时在gNB-CU-UP中具有DL数据缓冲的成功RRC连接恢复的过程的第二部分。图11在图10之后。
步骤S1024：假设存在I-RNTI并成功验证了认证令牌，则上次服务gNB-CU-CP分配gNB-CU UE F1AP ID，并决定让UE进入RRC_CONNECTED以转发缓冲的DL数据。基于存储的UE上下文，上次服务gNB-CU-CP经由F1接口将UE上下文建立请求消息(或新消息)发送到gNB-DU。UE上下文建立请求消息(或新消息)可以包括要设置的信令RB(SRB)ID和数据RB(DRB)ID(即要建立的承载列表)，以及用于F1-U的UL TNL地址信息(即F1-UL TEID)。
步骤S1026：gNB-DU经由F1接口利用UE上下文建立响应消息(或新消息)对上次服务gNB-CU-CP进行响应。UE上下文建立响应消息(或新消息)包含由gNB-DU提供的SRB和DRB(即接纳/拒绝的承载列表)的RLC/MAC/PHY配置，以及用于F1-U的DL TNL地址信息(即F1-DLTEID)。
步骤S1028：上次服务gNB-CU-CP经由E1接口将承载上下文修改请求消息(或新消息)发送到上次服务gNB-CU-UP。承载上下文修改请求消息(或新消息)包含用于F1-U的DLTNL地址信息(即，F1-DL TEID)。承载上下文修改请求消息(或新消息)可以包含更新的用户平面密钥(即，KUPenc，KUPint)。承载上下文修改请求消息(或新消息)可以包含下行链路数据缓冲指示IE和恢复指示IE。在UE进入RRC_CONNECTED之前，下行链路数据缓冲指示IE防止上次服务gNB-CU-UP向UE发送缓冲的DL数据。恢复指示IE用于向上次服务gNB-CU-UP指示处于RRC_INACTIVE的UE的RRC连接被恢复。
步骤S1030：上次服务gNB-CU-UP经由E1接口利用承载上下文修改响应消息(或新消息)对上次服务gNB-CU-CP进行响应。
步骤S1032：在从上次服务gNB-CU-UP接收到承载上下文修改响应消息(或新消息)后，上次服务gNB-CU-CP生成RRC恢复消息(或新消息)以通知UE从RRC_INACTIVE转换到RRC_CONNECTED。
步骤S1034：上次服务gNB-CU-CP经由F1接口将下行链路RRC消息传送消息(或新消息)发送到gNB-DU。下行链路RRC消息传送消息(或新消息)包括SRB ID和捎带RRC恢复消息的容器。
步骤S1036：gNB-DU通过由SRB ID指示的SRB1将RRC恢复消息(或新消息)转发到UE。
步骤S1038：UE基于RRC恢复消息(或新消息)中的重新配置信息恢复所有SRB和DRB，并重新建立AS安全性。UE现在处于RRC_CONNECTED。
步骤S1040：当上次服务gNB-CU-CP接收到针对RRC恢复消息的混合自动重传请求(HARQ)确认(ACK)时，上次服务gNB-CU-CP经由E1接口将数据转发开始指示消息发送到上次服务gNB-CU-UP，以允许上次服务gNB-CU-UP从现在开始向UE发起DL数据传输。可以上次服务gNB-CU-CP一将RRC恢复消息发送到UE，或者上次服务gNB-CU-CP一从UE接收到RRC恢复完成消息，就将数据转发开始指示消息发送到上次服务gNB-CU-UP。
步骤S1042：在从上次服务gNB-CU-CP接收到数据转发开始指示消息后，上次服务gNB-CU-UP经由gNB-DU向UE发送缓冲的DL数据。
步骤S1044：在步骤S1036中从gNB-DU接收到RRC恢复消息(或新消息)后，UE将RRC恢复完成消息(或新消息)发送到gNB-DU，以确认RRC连接被成功恢复。
步骤S1046：gNB-DU经由F1接口将上行链路RRC消息传送消息(或新消息)发送到上次服务gNB-CU-CP。上行链路RRC消息传送消息(或新消息)包括捎带RRC恢复完成消息的容器。
步骤S1048：如果UE具有要发送到NGC的UL数据，则UE可以经由gNB-DU和上次服务gNB-CU-UP将UL数据发送到UPF。
已在假设UE接入上次服务gNB的情况下描述了图10和图11中所示的本发明的实施方式2-1。但是，UE转换到RRC_INACTIVE之前的上次服务gNB与UE希望恢复连接的当前gNB可能不同。当UE接入相同的基于RAN的通知区域中的新gNB(即，当前gNB)时，图10和图11所示的本发明的实施方式2-1可以如下修改。
步骤S1002至S1012不被修改。但是，在这种情况下，由当前gNB-DU(而不是上次服务gNB-DU)发送的寻呼消息到达UE。
步骤S1014和S1016：由于处于RRC_INACTIVE的UE需要转换到RRC_CONNECTED，因此UE首先触发对当前gNB-DU的随机接入过程。
步骤S1018：为了恢复RRC连接，UE向当前gNB-DU发送RRC恢复请求消息(或新消息)。RRC恢复请求消息还包括由上次服务gNB分配的I-RNTI。I-RNTI用于在上次服务gNB-CU中识别UE上下文。
步骤S1020：在接收到RRC恢复请求消息(或新消息)后，当前gNB-DU经由F1接口将初始上行链路RRC消息传送消息(或新消息)发送到当前gNB-CU-CP。初始上行链路RRC消息传送消息可以包括捎带RRC恢复请求消息的容器。
步骤S1022：当前gNB-CU-CP如果能够解析I-RNTI中包含的gNB身份，则通过经由Xn接口发送获取UE上下文请求消息(或新消息)来请求上次服务gNB-CU-CP提供UE上下文。在从当前gNB-CU-CP接收到包括I-RNTI的获取UE上下文请求消息(或新消息)后，上次服务gNB-CU-CP检查是否能够找到与I-RNTI相关的UE上下文。
步骤S1024：假设存在I-RNTI并成功验证了认证令牌，则上次服务gNB-CU-CP经由Xn接口利用包含UE上下文的获取UE上下文响应消息来对当前gNB-CU-CP进行响应。当前gNB-CU-CP决定让UE进入RRC_CONNECTED以转发缓冲的DL数据。基于从上次服务gNB-CU-CP传递的UE上下文，当前gNB-CU-CP经由E1接口将承载上下文建立请求消息(或新消息)发送到当前gNB-CU-UP。承载上下文建立请求(或新消息)包含用于NG-U的UL TNL地址信息，以用于在当前gNB-CU-UP中设置承载上下文。当前gNB-CU-CP还将流到DRB映射以及SDAP和PDCP配置转发到当前gNB-CU-UP。当前gNB-CU-UP经由E1接口利用承载上下文建立响应消息(或新消息)对当前gNB-CU-CP进行响应。承载上下文建立响应消息(或新消息)包含用于F1-U的UL TNL地址信息、用于NG-U的DL TNL地址信息以及用于Xn-U的DL TNL地址信息。当前gNB-CU-CP经由F1接口向当前gNB-DU发送UE上下文建立请求(或新消息)。UE上下文建立请求(或新消息)可以包括要设置的SRB ID和DRB ID(即要设置的承载列表)，以及用于F1-U的ULTNL地址信息(即F1-UL TEID)。
步骤S1026：当前gNB-DU经由F1接口利用UE上下文建立响应消息(或新消息)对当前gNB-CU-CP进行响应。UE上下文建立响应消息(或新消息)包含由gNB-DU提供的SRB和DRB(即接纳/拒绝的承载列表)的RLC/MAC/PHY配置，以及用于F1-U的DL TNL地址信息(即F1-DLTEID)。
步骤S1028：当前gNB-CU-CP经由E1接口将承载上下文修改请求消息(或新消息)发送到当前gNB-CU-UP。承载上下文修改请求消息(或新消息)包含用于F1-U的DL TNL地址信息(即，F1-DL TEID)。承载上下文修改请求消息(或新消息)可以包含更新的用户平面密钥(即，KUPenc,KUPint)。承载上下文修改请求消息(或新消息)可以包括下行链路数据缓冲指示IE。在UE进入RRC_CONNECTED之前，下行链路数据缓冲指示IE防止当前gNB-CU-UP向UE发送缓冲的DL数据。
步骤S1030：当前gNB-CU-UP经由E1接口利用承载上下文修改响应消息(或新消息)对当前gNB-CU-CP进行响应。
步骤S1032：在从当前gNB-CU-UP接收到承载上下文修改响应消息(或新消息)后，当前gNB-CU-CP生成RRC恢复消息(或新消息)以通知UE从RRC_INACTIVE转换到RRC_CONNECTED。
步骤S1034：当前gNB-CU-CP经由F1接口将下行链路RRC消息传送消息(或新消息)发送到当前gNB-DU。下行链路RRC消息传送消息(或新消息)包括SRB ID和捎带RRC恢复消息的容器。
步骤S1036：当前gNB-DU通过由SRB ID指示的SRB1将RRC恢复消息(或新消息)转发给UE。
步骤S1038不被修改。
步骤S1040：当前gNB-CU-CP经由Xn接口将数据转发地址指示消息发送到上次服务gNB-CU-CP，以通知上次服务gNB-CU-CP在上次服务gNB-CU-UP处待决的DL用户数据能够被转发到的成功建立的PDU会话资源上下文。在接收到数据转发地址指示消息后，上次服务gNB-CU-CP经由E1接口将承载上下文释放命令消息发送到上次服务gNB-CU-UP，以便将待决的DL用户数据转发到指示的TNL地址。承载上下文释放命令消息包含用于Xn-U的DL TNL地址信息。上次服务gNB-CU-UP利用承载上下文释放完成消息进行响应。上次服务gNB-CU-UP将待决的DL用户数据转发到当前gNB-CU-UP。在从当前gNB-CU-CP接收到数据转发开始指示消息之前，当前gNB-CU-UP将从上次服务gNB-CU-UP转发的DL数据进行缓冲。
当当前gNB-CU-CP接收到针对RRC恢复消息的HARQ-ACK时，当前gNB-CU-CP经由E1接口将数据转发开始指示消息发送到当前gNB-CU-UP，以允许当前gNB-CU-UP从现在开始向UE发起DL数据传输。可以当前gNB-CU-CP一将RRC恢复消息发送到UE，或者当前gNB-CU-CP一从UE接收到RRC恢复完成消息，就将数据转发开始指示消息发送到当前gNB-CU-UP。
步骤S1042：在从当前gNB-CU-CP接收到数据转发开始指示消息后，当前gNB-CU-UP经由当前gNB-DU向UE发送缓冲的DL数据。
步骤S1044：在步骤S1036中从当前gNB-DU接收到RRC恢复消息(或新消息)后，UE将RRC恢复完成消息(或新消息)发送到当前gNB-DU，以确认RRC连接被成功恢复。
步骤S1046：当前gNB-DU经由F1接口将上行链路RRC消息传送消息(或新消息)发送到当前gNB-CU-CP。上行链路RRC消息传送消息(或新消息)包括捎带RRC恢复完成消息的容器。
步骤S1048：当前gNB-CU利用NGC执行路径切换过程。当前gNB-CU-CP触发上次服务gNB-CU-CP处的UE资源的释放。
根据图10和图11中描述的本发明的实施方式2-1，根据RRC恢复消息的传递，gNB-CU-CP能够有效地控制gNB-CU-UP是否将缓冲的DL数据转发到UE。因此，由于能够避免DL数据的丢失并且可以减少由于数据重传导致的不必要的时延，因此可以增强UE的体验。
4.实施方式2-2
根据本发明的实施方式2-2，gNB-CU-CP防止gNB-DU向UE转发缓冲的DL数据。当gNB-CU-CP知道UE的到RRC_CONNECTED的成功状态转换时，gNB-CU-CP通知gNB-DU被允许向UE发送缓冲的DL数据。当gNB-DU检测到RRC恢复消息成功发送到UE时，来自gNB-CU-CP的指示使gNB-DU能够开始将缓冲的DL数据转发给UE。对于UE对于寻呼暂时是不可达的情况，gNB-CU-CP还可以向gNB-CU-UP指示需要扩展的缓冲。
图12示出了根据本发明的实施方式2-2的总体过程。图12示出了当UE接入上次服务gNB时在gNB-DU中具有DL数据缓冲的成功RRC连接恢复的过程的第一部分。
UE处于RRC_INACTIVE。UE和上次服务gNB-CU存储UE上下文。上次服务gNB-CU-CP和AMF之间的NG-C连接被维持。另外，上次服务gNB-CU-UP和UPF之间的NG-U连接被维持。上次服务gNB-CU和gNB-DU之间的F1连接断开。
步骤S1202：当上次服务gNB-CU-UP接收到与处于RRC_INACTIVE的UE相关的PDU会话的DL数据，并且针对PDU会话上次服务gNB-CU-UP中没有存储F1-DL TEID时，上次服务gNB-CU-UP缓冲DL数据。
步骤S1204：在任何QoS流的第一个DL数据分组到达时，上次服务gNB-CU-UP将经由E1接口向上次服务gNB-CU-CP发送下行链路数据通知消息。该消息可以包括用于标识DL数据分组的QoS流的信息，以便支持gNB中的寻呼策略区分特征。
步骤S1205：当上次服务gNB-CU-CP检测到该UE对于寻呼暂时是不可达的时(例如，使用eDRX，或者该UE仅对于监管优先服务是可达的等)，上次服务gNB-CU-CP经由E1接口将RAN寻呼延迟消息发送到上次服务gNB-CU-UP。RAN寻呼延迟消息可能包含原因值IE和等待时间IE，以便请求扩展的缓冲。原因值IE用于指示下行链路数据通知消息被暂时拒绝的原因。等待时间IE是在能够建立/恢复到UE的无线电承载之前的期望时间。
原因值IE和等待时间IE可以经由针对下行链路数据通知消息的响应消息发送到上次服务gNB-CU-UP。
步骤S1206：在步骤S1204中从上次服务gNB-CU-UP接收到下行链路数据通知消息后，上次服务gNB-CU-CP发起RAN寻呼以在基于RAN的通知区域中找到UE。如果由AMF配置了寻呼策略区分，则映射到用于在下行链路数据通知消息中标识DL数据分组的QoS流的信息的RAN寻呼优先级IE可以被包括在RAN寻呼消息中。
步骤S1208：上次服务gNB-CU-CP经由Xn接口将RAN寻呼消息发送到同一基于RAN的通知区域中的相邻gNB。
步骤S1210
Figure BDA0002715490020000281
S1212：同一基于RAN的通知区域中的各个gNB-CU经由F1接口将寻呼消息发送到gNB-DU。如果RAN寻呼优先级IE被包含在RAN寻呼消息中，则gNB-CU-CP可以使用它来优先化寻呼。然后，各个gNB-DU将寻呼消息发送到UE。在这种情况下，由上次服务gNB-DU发送的寻呼消息到达UE。
步骤S1214：由于处于RRC_INACTIVE的UE需要转换到RRC_CONNECTED，因此UE首先将随机接入前导码或新消息发送到gNB-DU。
步骤S1216：在从UE接收到随机接入前导码后，gNB-DU随后利用随机接入响应进行响应。
步骤S1218：为了恢复RRC连接，UE将RRC恢复请求消息(或新消息)发送到gNB-DU。RRC恢复请求消息还包括用于在上次服务gNB-CU中识别UE上下文的I-RNTI。
步骤S1220：在接收到RRC恢复请求消息(或新消息)后，gNB-DU经由F1接口将初始上行链路RRC消息传送消息(或新消息)发送到上次服务gNB-CU-CP。初始上行链路RRC消息传送消息可以包括捎带RRC恢复请求消息的容器。
步骤S1222：在接收到包括用于包括I-RNTI的RRC恢复请求消息的容器的初始上行链路RRC消息传送消息后，上次服务gNB-CU-CP检查是否能够找到与I-RNTI有关的UE上下文。
图13示出了根据本发明的实施方式2-2的总体过程。图13示出了当UE接入上次服务gNB时在gNB-DU中具有DL数据缓冲的成功RRC连接恢复的过程的第二部分。图13在图12之后。
步骤S1224：假设存在I-RNTI并成功验证了认证令牌，则上次服务gNB-CU-CP分配gNB-CU UE F1AP ID，并决定让UE进入RRC_CONNECTED以转发缓冲的DL数据。基于存储的UE上下文，上次服务gNB-CU-CP经由F1接口将UE上下文建立请求消息(或新消息)发送到gNB-DU。UE上下文建立请求消息(或新消息)可以包括要设置的SRB ID和DRB ID(即要设置的承载列表)，以及用于F1-U的UL TNL地址信息(即F1-UL TEID)。UE上下文建立请求消息(或新消息)可以包括下行链路数据缓冲指示IE。在UE进入RRC_CONNECTED之前，下行链路数据缓冲指示IE防止gNB-DU向UE发送缓冲的DL数据。
步骤S1226：gNB-DU经由F1接口利用UE上下文建立响应消息(或新消息)对上次服务gNB-CU-CP进行响应。UE上下文建立响应消息(或新消息)包含由gNB-DU提供的SRB和DRB(即接纳/拒绝的承载列表)的RLC/MAC/PHY配置，以及用于F1-U的DL TNL地址信息(即F1-DLTEID)。
步骤S1228：上次服务gNB-CU-CP经由E1接口将承载上下文修改请求消息(或新消息)发送到上次服务gNB-CU-UP。承载上下文修改请求消息(或新消息)包含用于F1-U的DLTNL地址信息(即，F1-DL TEID)。承载上下文修改请求消息(或新消息)可以包含更新的用户平面密钥(即，KUPenc,KUPint)。承载上下文修改请求消息(或新消息)可能包含恢复指示IE。恢复指示IE用于向上次服务gNB-CU-UP指示处于RRC_INACTIVE的UE的RRC连接被恢复。
步骤S1230：上次服务gNB-CU-UP经由E1接口利用承载上下文修改响应消息(或新消息)对上次服务gNB-CU-CP进行响应。
步骤S1232：由于上次服务gNB-CU-UP现在知道PDU会话的F1-DL TEID，因此上次服务gNB-CU-UP发起将缓冲的DL数据转发到gNB-DU。gNB-DU可以缓冲从上次服务gNB-CU-UP接收到的DL数据。
步骤S1234：在从上次服务gNB-CU-UP接收到承载上下文修改响应消息(或新消息)后，上次服务gNB-CU-CP生成RRC恢复消息(或新消息)以通知UE从RRC_INACTIVE转换到RRC_CONNECTED。
步骤S1236：上次服务gNB-CU-CP经由F1接口将下行链路RRC消息传送消息(或新消息)发送到gNB-DU。下行链路RRC消息传送消息(或新消息)包括SRB ID和捎带RRC恢复消息的容器。如果数据转发开始指示IE包含在下行链路RRC消息传送消息(或新消息)中，则gNB-DU一接收到针对步骤S1236中捎带的RRC恢复消息的HARQ-ACK，gNB-DU就开始将缓冲的DL数据发送到UE。
另选地，上次服务gNB-CU-CP可以经由F1接口将数据转发开始指示消息发送到gNB-DU，以允许gNB-DU将缓冲的DL数据发送到UE。
步骤S1238：gNB-DU通过由SRB ID指示的SRB1将RRC恢复消息(或新消息)转发到UE。
步骤S1240：UE基于RRC恢复消息(或新消息)中的重新配置信息恢复所有SRB和DRB，并重新建立AS安全性。UE现在处于RRC_CONNECTED。
步骤S1242：如果在步骤S1236中接收到数据转发开始指示IE，则gNB-DU一接收到针对在步骤S1236中捎带的RRC恢复消息的HARQ-ACK，gNB-DU就开始将缓冲的DL数据发送到UE。
另选地，如果上次服务gNB-CU-CP通过在下面描述的步骤S1246之后发送数据转发开始指示消息来允许gNB-DU向UE发送缓冲的DL数据，则可以在步骤S1246之后在gNB-DU处发起DL数据传输。
步骤S1244：在步骤S1236中从gNB-DU接收到RRC恢复消息(或新消息)后，UE将RRC恢复完成消息(或新消息)发送到gNB-DU，以确认RRC连接被成功恢复。
步骤S1246：gNB-DU经由F1接口将上行链路RRC消息传送消息(或新消息)发送到上次服务gNB-CU-CP。上行链路RRC消息传送消息(或新消息)包括捎带RRC恢复完成消息的容器。
步骤S1248：如果UE具有要发送到NGC的UL数据，则UE可以经由gNB-DU和上次服务gNB-CU-UP将UL数据发送到UPF。
已经在假设UE接入上次服务gNB的情况下描述了图12和图13所示的本发明的实施方式2-2。但是，UE转换到RRC_INACTIVE之前的上次服务gNB与UE希望恢复连接的当前gNB可能不同。当UE接入相同的基于RAN的通知区域中的新gNB(即，当前gNB)时，可以如下修改图12和图13所示的本发明的实施方式2-2。
步骤S1202至S1212不被修改。但是，在这种情况下，由当前gNB-DU而不是上次服务gNB-DU发送的寻呼消息将到达UE。
步骤S1214：由于处于RRC_INACTIVE的UE需要转换到RRC_CONNECTED，因此UE首先将随机接入前导码或新消息发送到gNB-DU。
步骤S1216：在从UE接收到随机接入前导码后，gNB-DU随后利用随机接入响应进行响应。
步骤S1218：为了恢复RRC连接，UE将RRC恢复请求消息(或新消息)发送到gNB-DU。RRC恢复请求消息还包括用于在上次服务gNB-CU中识别UE上下文的I-RNTI。
步骤S1220：在接收到RRC恢复请求消息(或新消息)后，gNB-DU经由F1接口将初始上行链路RRC消息传送消息(或新消息)发送到上次服务gNB-CU-CP。初始上行链路RRC消息传送消息可以包括捎带RRC恢复请求消息的容器。
步骤S1222：在接收到包括用于包括I-RNTI的RRC恢复请求消息的容器的初始上行链路RRC消息传输消息后，上次服务gNB-CU-CP检查是否能够找到与I-RNTI有关的UE上下文。
步骤S1214和步骤S1216：由于处于RRC_INACTIVE的UE需要转换到RRC_CONNECTED，因此UE首先触发对当前gNB-DU的随机接入过程。
步骤S1218：为了恢复RRC连接，UE向当前gNB-DU发送RRC恢复请求消息(或新消息)。RRC恢复请求消息还包括由上次服务gNB分配的I-RNTI。I-RNTI用于在上次服务gNB-CU中识别UE上下文。
步骤S1220：接收到RRC恢复请求消息(或新消息)后，当前gNB-DU经由F1接口将初始上行链路RRC消息传送消息(或新消息)发送到当前gNB-CU-CP。初始上行链路RRC消息传送消息可以包括捎带RRC恢复请求消息的容器。
步骤S1222：当前gNB-CU-CP如果能够解析I-RNTI中包含的gNB身份，则通过经由Xn接口发送获取UE上下文请求消息(或新消息)来请求上次服务gNB-CU-CP提供UE上下文。在从当前gNB-CU-CP接收到包括I-RNTI的获取UE上下文请求消息(或新消息)后，上次服务gNB-CU-CP检查是否能够找到与I-RNTI相关的UE上下文。
步骤S1224：假设存在I-RNTI并成功验证了认证令牌，则上次服务gNB-CU-CP经由Xn接口利用包含UE上下文的获取UE上下文响应消息来对当前gNB-CU-CP进行响应。当前gNB-CU-CP决定让UE进入RRC_CONNECTED以转发缓冲的DL数据。基于从上次服务gNB-CU-CP传递的UE上下文，当前gNB-CU-CP经由E1接口将承载上下文建立请求消息(或新消息)发送到当前gNB-CU-UP。承载上下文建立请求(或新消息)包含用于NG-U的UL TNL地址信息，以用于在当前gNB-CU-UP中建立承载上下文。当前gNB-CU-CP还将流到DRB映射以及SDAP和PDCP配置转发到当前gNB-CU-UP。当前gNB-CU-UP经由F1接口利用承载上下文建立响应消息(或新消息)对当前gNB-CU-CP进行响应。承载上下文建立响应消息(或新消息)包含用于F1-U的UL TNL地址信息、用于NG-U的DL TNL地址信息以及用于Xn-U的DL TNL地址信息。当前gNB-CU-CP经由F1接口向当前gNB-DU发送UE上下文建立请求(或新消息)。UE上下文建立请求(或新消息)可以包括要设置的SRB ID和DRB ID(即要设置的承载列表)，以及用于F1-U的ULTNL地址信息(即F1-UL TEID)。UE上下文建立请求消息(或新消息)可以包括下行链路数据缓冲指示IE。在UE进入RRC_CONNECTED之前，下行链路数据缓冲指示IE防止当前gNB-DU向UE发送缓冲的DL数据。
步骤S1226：当前gNB-DU经由F1接口利用UE上下文建立响应消息(或新消息)对当前gNB-CU-CP进行响应。UE上下文建立响应消息(或新消息)包含由gNB-DU提供的SRB和DRB(即接纳/拒绝的承载列表)的RLC/MAC/PHY配置，以及用于F1-U的DL TNL地址信息(即，F1-DL TEID)。
步骤S1228：当前gNB-CU-CP经由E1接口将承载上下文修改请求消息(或新消息)发送到当前gNB-CU-UP。承载上下文修改请求消息(或新消息)包含用于F1-U的DL TNL地址信息(即，F1-DL TEID)。承载上下文修改请求消息(或新消息)可以包含更新的用户平面密钥(即，KUPenc,KUPint)。
步骤S1230：当前gNB-CU-UP经由E1接口利用承载上下文修改响应消息(或新消息)对当前gNB-CU-CP进行响应。
省略步骤S1232。
步骤S1234：在从当前gNB-CU-UP接收到承载上下文修改响应消息(或新消息)后，当前gNB-CU-CP生成RRC恢复消息(或新消息)以通知UE从RRC_INACTIVE转换到RRC_CONNECTED。
步骤S1236：当前gNB-CU-UP经由F1接口将下行链路RRC消息传送消息(或新消息)发送到当前gNB-DU。下行链路RRC消息传送消息(或新消息)包括SRB ID和捎带RRC恢复消息的容器。如果数据转发开始指示IE包含在下行链路RRC消息传送消息(或新消息)中，则当前gNB-DU一接收到针对在步骤S1236中捎带的RRC恢复消息的HARQ-ACK，当前gNB-DU就开始将缓冲的DL数据发送到UE。
另选地，当前gNB-CU-CP可以经由F1接口将数据转发开始指示消息发送到当前gNB-DU，以允许当前gNB-DU向UE发送缓冲的DL数据。
步骤S1238：当前gNB-DU通过由SRB ID指示的SRB1将RRC恢复消息(或新消息)转发给UE。
步骤S1240不被修改。
步骤S1242：当前gNB-CU-CP经由Xn接口将数据转发地址指示消息发送到上次服务gNB-CU-CP，以通知上次服务gNB-CU-CP在上次服务gNB-CU-UP处待决的DL用户数据能够被转发到的成功建立的PDU会话资源上下文。在接收到数据转发地址指示消息后，上次服务gNB-CU-CP经由E1接口将承载上下文释放命令消息发送到上次服务gNB-CU-UP，以便将待决的DL用户数据转发到指示的TNL地址。承载上下文释放命令消息包含用于Xn-U的DL TNL地址信息。上次服务gNB-CU-UP利用承载上下文释放完成消息进行响应。上次服务gNB-CU-UP将待决的DL用户数据转发到当前gNB-CU-UP。由于当前gNB-CU-UP现在知道PDU会话的F1-DLTEID，因此当前gNB-CU-UP发起将缓冲的DL数据转发到当前gNB-DU。如果UE还没有进入RRC_CONNECTED，则当前gNB-DU可以缓冲从当前gNB-CU-UP接收的DL数据。如果当前gNB-DU知道在UE中接收到RRC恢复消息，则当前gNB-DU将DL数据转发给UE。
步骤S1244：当在步骤S1236中从当前gNB-DU接收到RRC恢复消息(或新消息)后，UE将RRC恢复完成消息(或新消息)发送到当前gNB-DU，以确认RRC连接已成功恢复。
步骤S1246：当前gNB-DU经由F1接口将上行链路RRC消息传送消息(或新消息)发送到当前gNB-CU-CP。上行链路RRC消息传送消息(或新消息)包括捎带RRC恢复完成消息的容器。
步骤S1248：当前gNB-CU通过NGC执行路径切换过程。当前gNB-CU-CP触发上次服务gNB-CU-CP处的UE资源的释放。
根据图12和图13中描述的本发明的实施方式2-2，根据RRC恢复消息的传递，gNB-CU-CP可以有效地控制gNB-DU是否将缓冲的DL数据转发给UE。因此，由于可以避免DL数据的丢失并且可以减少由于数据重传导致的不必要的时延，因此可以增强UE的体验。因为接收HARQ-ACK的MAC层位于gNB-DU中，所以可以比本发明的实施方式2-1更快地将缓冲的DL数据发送到UE。但是，gNB-DU可能会受到缓冲区大小的限制。
上述本发明还可以应用于LTE情况下的CU-DU划分，以恢复窄带(NB)物联网(IoT)UE和轻度连接的UE中的UE上下文。
鉴于本文所描述的示例性***，参照多个流程图描述了可根据所公开的主题实现的方法。尽管为了简单起见，方法被示出并描述为一系列步骤或方框，但将理解和意识到，要求保护的主题不受步骤或方框的次序限制，因为一些步骤可按照与本文所描绘和描述的不同次序发生或与其它步骤同时发生。此外，本领域技术人员将理解，流程图中所示的步骤不是排他性的，在不影响本公开的范围的情况下，可包括其它步骤或者可删除示例流程图中的一个或更多个步骤。

Claims (14)

1.一种由无线通信***中的gNB的中央单元CU用户平面UP执行的方法，该方法包括以下步骤：
从所述gNB的CU控制平面CU-CP接收缓冲数据丢弃指示；以及
基于所述缓冲数据丢弃指示，丢弃用户设备UE的缓冲数据，
其中，所述CU-CP是构成所述gNB的托管无线电资源控制RRC协议和分组数据汇聚协议PDCP-C协议的逻辑节点，并且
其中，所述CU-UP是构成所述gNB的托管PDCP-U协议的逻辑节点。
2.根据权利要求1所述的方法，其中，所述缓冲数据丢弃指示表明针对所述UE发生了无线电接入网RAN寻呼失败。
3.根据权利要求1所述的方法，该方法还包括以下步骤：保持存储所述UE的上下文。
4.根据权利要求3所述的方法，其中，维持所述CU-UP与用户平面功能UPF之间的连接。
5.根据权利要求3所述的方法，其中，维持所述CU-CP与接入和移动性管理功能AMF之间的连接。
6.根据权利要求1所述的方法，其中，所述缓冲数据丢弃指示是经由承载上下文修改请求消息来发送的。
7.根据权利要求6所述的方法，其中，所述缓冲数据丢弃指示为所述承载上下文修改请求消息中的信息元素IE。
8.无线通信***中的gNB的中央单元-用户平面CU-UP，其中，所述CU-CP被配置为：
从所述gNB的CU控制平面CU-CP接收缓冲数据丢弃指示；以及
基于所述缓冲数据丢弃指示，丢弃用户设备UE的缓冲数据，
其中，所述CU-CP是构成所述gNB的托管无线电资源控制RRC协议和分组数据汇聚协议PDCP-C协议的逻辑节点，并且
其中，所述CU-UP是构成所述gNB的托管PDCP-U协议的逻辑节点。
9.根据权利要求8所述的CU-CP，其中，所述缓冲数据丢弃指示表明针对所述UE发生了无线电接入网RAN寻呼失败。
10.根据权利要求8所述的CU-CP，其中，所述CU-CP还被配置为保持存储所述UE的上下文。
11.根据权利要求10所述的CU-CP，其中，维持所述CU-UP与用户平面功能UPF之间的连接。
12.根据权利要求10所述的CU-CP，其中，维持所述CU-CP与接入和移动性管理功能AMF之间的连接。
13.根据权利要求8所述的CU-CP，其中，所述缓冲数据丢弃指示是经由承载上下文修改请求消息来发送的。
14.根据权利要求13所述的CU-CP，其特征在于，所述缓冲数据丢弃指示为所述承载上下文修改请求消息中的信息元素IE。
CN201980024702.4A 2018-04-02 2019-04-01 在cp-up分离中保持连接时丢弃缓冲数据的方法和设备 Active CN111989981B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
KR20180038199 2018-04-02
KR10-2018-0038199 2018-04-02
PCT/KR2019/003779 WO2019194486A1 (en) 2018-04-02 2019-04-01 Method and apparatus for discarding buffered data while keeping connection in cp-up separation

Publications (2)

Publication Number Publication Date
CN111989981A true CN111989981A (zh) 2020-11-24
CN111989981B CN111989981B (zh) 2023-08-22

Family

ID=68100973

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201980024702.4A Active CN111989981B (zh) 2018-04-02 2019-04-01 在cp-up分离中保持连接时丢弃缓冲数据的方法和设备

Country Status (4)

Country Link
US (1) US11510268B2 (zh)
EP (1) EP3747236B1 (zh)
CN (1) CN111989981B (zh)
WO (1) WO2019194486A1 (zh)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019193553A1 (en) * 2018-04-06 2019-10-10 Telefonaktiebolaget Lm Ericsson (Publ) Qos flow management over e1
US11412554B2 (en) * 2018-05-10 2022-08-09 Apple Inc. E1 interface setup in NG-RAN
AU2019292724B2 (en) * 2018-06-25 2021-11-04 Telefonaktiebolaget Lm Ericsson (Publ) Radio network node, user plane function (UPF) and methods performed therein for paging policy differentiation
WO2020033451A1 (en) * 2018-08-10 2020-02-13 Intel Corporation Enhancing user plane contexts management in new radio (nr)
US20210360727A1 (en) * 2018-10-05 2021-11-18 Google Llc User Equipment Context Transfer Over Radio Access Network Paging
CN113316973A (zh) * 2019-01-18 2021-08-27 中兴通讯股份有限公司 移除多连接***中的用户平面连接的方法和装置
US20220116794A1 (en) * 2019-02-15 2022-04-14 Telefonaktiebolaget Lm Ericsson (Publ) Automatic central unit user plane creation
WO2020223919A1 (en) * 2019-05-08 2020-11-12 Lenovo (Beijing) Limited Method and apparatus for radio link flow control
CN112822789A (zh) * 2019-11-18 2021-05-18 中兴通讯股份有限公司 非激活态终端的重定向方法、电子设备及计算机可读介质
KR20210094955A (ko) * 2020-01-22 2021-07-30 삼성전자주식회사 차세대 이동통신 시스템에서 조건적 핸드오버 (Conditional Handover)와 듀얼 스택 프로토콜 핸드오버 (Dual Stack Protocol Handover) 시 데이터 포워딩 지원 방법
EP4079042A4 (en) 2020-05-29 2023-06-14 Samsung Electronics Co., Ltd. METHOD AND DEVICE FOR SUPPORTING INTERCELLULAR TRANSFER
CN113747524A (zh) * 2020-05-29 2021-12-03 北京三星通信技术研究有限公司 支持切换的方法和设备
WO2022025818A1 (en) * 2020-07-31 2022-02-03 Telefonaktiebolaget Lm Ericsson (Publ) Handling of buffered traffic during inter-cu migration of an ancestor integrated access backhaul (iab) node
KR20230047374A (ko) * 2020-08-06 2023-04-07 지티이 코포레이션 멀티캐스트 브로드캐스트 서비스를 위한 시그널링
WO2022077315A1 (en) 2020-10-15 2022-04-21 Zte Corporation Method, device, and system for paging resource selection and system information transmission/acquisition in wireless networks
WO2022078867A1 (en) * 2020-10-15 2022-04-21 Nokia Technologies Oy Methods, apparatuses and computer program for data transmission in inactive state
WO2022200033A1 (en) * 2021-03-26 2022-09-29 Nokia Technologies Oy Data transmission in inactive state connection
CN118202627A (zh) * 2022-09-29 2024-06-14 北京小米移动软件有限公司 一种丢包处理方法及装置

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090175241A1 (en) * 2008-01-07 2009-07-09 Fujitsu Limited Method for dropping packet data, radio communication device, and mobile communication system
EP2416606A1 (en) * 2009-03-31 2012-02-08 Telefonaktiebolaget LM Ericsson (publ) Apparatus and method for moving wcdma mobile station inthe manner of the least packet loss
EP3089515A1 (en) * 2015-04-30 2016-11-02 Alcatel Lucent Apparatuses, methods and computer programs for a mobility management unit of a first and a second mobile communication system and a mobile transceiver
WO2018004278A1 (ko) * 2016-07-01 2018-01-04 주식회사 케이티 이중 연결 상태에서 데이터를 송수신하는 방법 및 그 장치
WO2018009340A1 (en) * 2016-07-05 2018-01-11 Intel Corporation Systems, methods and devices for control-user plane separation for 5g radio access networks
WO2018008925A1 (ko) * 2016-07-05 2018-01-11 엘지전자 주식회사 단말에 대한 페이징의 실패를 mme에게 알리는 방법 및 장치
US20180083688A1 (en) * 2016-08-09 2018-03-22 Samsung Electronics Co., Ltd. Method and apparatus for managing user plane operation in wireless communication system

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018056347A1 (ja) * 2016-09-21 2018-03-29 京セラ株式会社 基地局及び無線端末
CN110546975B (zh) * 2017-03-17 2021-06-04 三星电子株式会社 无线电接入网络通知区域更新失败
US10932168B2 (en) * 2017-09-29 2021-02-23 Apple Inc. Next generation node-B (gNB) and methods for mobility management with separate user plane and control plane in new radio (NR) systems
US10716096B2 (en) * 2017-11-07 2020-07-14 Apple Inc. Enabling network slicing in a 5G network with CP/UP separation
US11153271B2 (en) * 2018-02-16 2021-10-19 Apple Inc. Managing bearers in a radio access network

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090175241A1 (en) * 2008-01-07 2009-07-09 Fujitsu Limited Method for dropping packet data, radio communication device, and mobile communication system
EP2416606A1 (en) * 2009-03-31 2012-02-08 Telefonaktiebolaget LM Ericsson (publ) Apparatus and method for moving wcdma mobile station inthe manner of the least packet loss
EP3089515A1 (en) * 2015-04-30 2016-11-02 Alcatel Lucent Apparatuses, methods and computer programs for a mobility management unit of a first and a second mobile communication system and a mobile transceiver
WO2018004278A1 (ko) * 2016-07-01 2018-01-04 주식회사 케이티 이중 연결 상태에서 데이터를 송수신하는 방법 및 그 장치
WO2018009340A1 (en) * 2016-07-05 2018-01-11 Intel Corporation Systems, methods and devices for control-user plane separation for 5g radio access networks
WO2018008925A1 (ko) * 2016-07-05 2018-01-11 엘지전자 주식회사 단말에 대한 페이징의 실패를 mme에게 알리는 방법 및 장치
US20180083688A1 (en) * 2016-08-09 2018-03-22 Samsung Electronics Co., Ltd. Method and apparatus for managing user plane operation in wireless communication system

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
CATT: "R3-173612 \"Discussion on RAN Paging failure\"", 3GPP TSG_RAN\\WG3_IU, no. 3 *
ERICSSON: "R3-172549 \"Dual Connectivity deployment options and relation to XnUP/X2UP/F1UP\"", 3GPP TSG_RAN\\WG3_IU, no. 3 *
HUAWEI, INTEL CORPORATION: "R3-173703 \"RAN paging failure handling\"", 3GPP TSG_RAN\\WG3_IU, no. 3 *
INTEL CORPORATION: "\"R3-174630 Intra CU-CP handover_v1\"", 3GPP TSG_RAN\\WG3_IU *
KT CORP.: "R3-173810 \"Resource Management for Separation of CP and UP in CU\"", 3GPP TSG_RAN\\WG3_IU, no. 3 *
NTT DOCOMO,INC.: "\"R3-174846 How to acquire status of re-transmitted packets\"", 3GPP TSG_RAN\\WG3_IU *

Also Published As

Publication number Publication date
EP3747236A4 (en) 2021-04-07
EP3747236B1 (en) 2023-02-15
CN111989981B (zh) 2023-08-22
US20210185755A1 (en) 2021-06-17
WO2019194486A1 (en) 2019-10-10
EP3747236A1 (en) 2020-12-09
US11510268B2 (en) 2022-11-22

Similar Documents

Publication Publication Date Title
CN111989981B (zh) 在cp-up分离中保持连接时丢弃缓冲数据的方法和设备
JP7145285B2 (ja) 無線通信システムにおける次のメッセージのために使われるベアラのタイプを指示する方法及び装置
RU2733066C1 (ru) СПОСОБ И УСТРОЙСТВО ДЛЯ ПЕРЕДАЧИ ПРАВИЛА ДЛЯ ОТОБРАЖЕНИЯ ПОТОКА QoS В DRB
US10785778B2 (en) Method for handling for an uplink split operation in wireless communication system and a device therefor
US9986462B2 (en) Double-connection implementation method and base station
EP3550876A1 (en) Method and apparatus for establishing drb
EP3666035B1 (en) Method and apparatus for keeping dc configuration
JP6935585B2 (ja) マッピング規則を修正する方法及び装置
JP2019522443A (ja) Ｃｕ−ｄｕ分割シナリオにおけるデータを送信する方法及び装置
CN109428818B (zh) 处理分组路由的装置及方法
EP3541114A1 (en) Sending data rate information to a wireless access network node
WO2013184770A1 (en) Method and system for multi-rat transmission
WO2015021412A1 (en) Method and system for protocol layer enhancements in data offload over small cells
WO2014113236A1 (en) Communicating data using a local wireless access network node
CN111148163B (zh) 通信方法及装置
EP3664507B1 (en) Communication methods for a master base station and a terminal
JP2020528684A (ja) Ｓｃｇ構成を維持する方法及び装置
US20230180327A1 (en) Communication control method
CN110710323A (zh) 支持无线通信***中的承载类型改变的方法和设备
CN109219094B (zh) 基站切换及实例分配方法、rlc协议实现设备、基站及终端
US20230328607A1 (en) Communication control method
CN117616806A (zh) 用于处置节点迁移的第一节点、第二节点以及由此执行的方法
CN112703766B (zh) 由无线通信节点执行的方法、无线通信节点
CN109803390B (zh) 消息、策略发送方法及装置，存储介质，处理器
US20240073736A1 (en) Communication control method

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant