CN113424587A - 用于在无线通信系统中控制ue上下文的方法和装置 - Google Patents

用于在无线通信系统中控制ue上下文的方法和装置 Download PDF

Info

Publication number
CN113424587A
CN113424587A CN202080014585.6A CN202080014585A CN113424587A CN 113424587 A CN113424587 A CN 113424587A CN 202080014585 A CN202080014585 A CN 202080014585A CN 113424587 A CN113424587 A CN 113424587A
Authority
CN
China
Prior art keywords
node
message
context
update
context update
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.)
Pending
Application number
CN202080014585.6A
Other languages
English (en)
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.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
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 Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Priority claimed from PCT/KR2020/002112 external-priority patent/WO2020167028A1/en
Publication of CN113424587A publication Critical patent/CN113424587A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
    • H04W8/24—Transfer of terminal data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0022—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0033—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0055—Transmission or use of information for re-establishing the radio link
    • H04W36/0069—Transmission or use of information for re-establishing the radio link in case of dual connectivity, e.g. decoupled uplink/downlink
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08—Mobility data transfer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/08—Access point devices
    • H04W88/085—Access point devices with remote components
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/16—Interfaces between hierarchically similar devices
    • H04W92/20—Interfaces between hierarchically similar devices between access points

Landscapes

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

Abstract

本公开涉及用于将支持超过第四代(4G)系统的更高数据速率的第五代(5G)通信系统与物联网(IoT)技术融合的通信方法和系统。本公开可以被应用于基于5G通信技术和IoT相关技术的智能服务，诸如智能家居、智能楼宇、智能城市、智能汽车、车联网、医疗保健、数字教育、智能零售、安防和安全服务。提供了用于在多个节点之间控制用户设备(UE)上下文的方法和装置。该方法包括向第二节点发送请求用户设备(UE)上下文更新的第一消息，响应于第一消息的发送从第二节点接收指示UE上下文更新完成的第二消息或指示UE上下文更新失败的第三消息，并且基于第二消息或第三消息的接收来确定是否向第二节点重发送第一消息。UE上下文更新的过程可以通过从第二节点向第三节点发送请求在UE和第三节点之间执行的UE上下文更新的操作的消息来启动。

Description

用于在无线通信系统中控制UE上下文的方法和装置
技术领域
本公开涉及用于在多个节点之间控制用户设备(UE)上下文的方法和装置。
背景技术
为了满足第四代(4G)通信系统商用化后趋于增加的无线数据流量需求，增强型第五代(5G)通信系统或预5G(pre-5G)通信系统正在被努力开发。为此，5G通信系统或预5G通信系统被称为超4G网络通信系统或后长期演进(LTE)系统。为了实现高数据传输速率(datatransfer rate)，5G通信系统被认为是在毫米波频段(例如60GHz频段)中实施的。为了减少电波的损耗并且增加电波在毫米波频段的传送距离(transfer distance)，波束成形(beamforming)、大规模多入多出(massive MIMO)、全维多入多出(FD-MIMO)、阵列天线(array antenna)、模拟波束成形(analog beam-forming)、大型天线(large-scaleantenna)技术在5G通信系统中正在被讨论。此外，为了改进系统的网络，诸如改进小小区(improved small cell)、高级小小区(advanced small cell)、云无线接入网(cloudRAN)、超密集网络(ultra-dense network)、设备到设备通信(D2D)、无线回程(wirelessbackhaul)、移动网络(moving network)、协作通信(cooperative communication)、协调式多点(CoMP)和接收干扰消除(reception interference cancellation)的技术在5G通信系统中被开发。此外，属于高级编码调制(ACM)方案的混合频移键控(hybrid frequencyshift key)和正交振幅调制(QAM)调制(FQAM)和滑动窗口叠加编码(SWSC)、改进的滤波器组多载波(improved FBMC)、非正交多址接入(NOMA)和稀疏码多址接入(SCMA)在5G系统中正在被开发。
互联网从人类在其上生成和消耗信息的以人为中心的连接网络演进到在诸如物的分布式元素之间进行信息交换和处理的物联网(IoT)。作为大数据处理技术通过与云服务器的连接而与IoT技术相结合的万物互联(IoE)技术正在兴起。为了实施IoT，需要诸如感测技术、有线/无线通信和网络基础设施、服务接口技术和安防技术的技术元素。因此，用于物之间的连接的技术，诸如传感器网络、机器对机器(M2M)和机器类型通信(MTC)，最近正在被研究。
此外，在IoT环境中，可以提供通过收集和分析被连接的物产生的数据来为人类生活创造新的价值的智能互联网技术(Internet technology，IT)服务。IoT可以通过对现有的信息技术(information technology，IT)与各行业之间的融合和组合来应用于诸如智能家居、智能楼宇、智能城市、智能汽车或车联网、智能电网、医疗保健、智能家电和高级医疗服务(advanced medical services)的领域。
在5G技术中，已经引入了LTE技术和新无线电(NR)技术在其中共同操作的非独立(NSA)新无线电(NR)标准，并且支持LTE基站和NR基站之间的演进的通用陆地无线电接入(EUTRA)NR双连接(EN-DC)结构。在这样的多无线电接入技术(RAT)双连接类型的连接结构中，诸如终端的装置使用LTE基站作为主节点(master node)并且使用NR基站作为辅节点(secondary node)来执行无线电接入。
此外，随着无线通信过程中请求处理数据量呈爆炸式增长，将基站内现有协议层分离并实施为中央单元(CU)和分布式单元(DU)的技术已经被引入5G中。单个基站中包括的用以配置协议栈的层被分离为CU基站和DU基站，并且在CU基站和DU基站之间配置前传接口，因此能够发送和接收信令。
上述信息仅作为协助理解本公开的背景信息而被呈现。而没有做出关于上述任何部分是否可能适用于作为关于本公开的现有技术的确定和断言。
发明内容
技术问题
如果UE在UE已经在EN-DC连接结构中接入了LTE基站和NR基站的状态下需要UE上下文的改变或更新，那么在诸如从NR基站和LTE基站分离出的CU基站和DU基站的若干节点之间高效地执行信令操作是必要的。
技术方案
根据本公开的一个方面，提供了无线通信系统中的第一节点的方法。该方法包括向第二节点发送(transmit)请求用户设备(UE)上下文更新的第一消息，响应于第一消息的发送，从第二节点接收指示UE上下文更新的完成的第二消息或指示UE上下文更新的失败的第三消息，并且基于第二消息或第三消息的接收来确定是否向第二节点重发送(retransmit)第一消息。UE上下文更新的过程可以由请求在UE和第三节点之间执行的UE上下文更新的操作的消息从第二节点向第三节点的发送来启动。
根据本公开的另一个方面，提供了无线通信系统中的第二节点的方法。该方法包括从第一节点接收请求用户设备(UE)上下文更新的第一消息，响应于第一消息的接收向第三节点发送请求在第三节点和UE之间执行的UE上下文更新的操作的消息，确认基于向第三节点发送的消息而被启动的UE上下文更新的结果，并且基于确认的结果向第一节点发送指示UE上下文更新的完成的第二消息或者指示UE上下文更新的失败的第三消息。
根据本公开的另一个方面，提供了无线通信系统中的第一节点。第一节点包括收发器以及至少一个处理器，处理器被配置为控制收发器向第二节点发送请求用户设备(UE)上下文更新的第一消息，以及响应于第一消息的发送，从第二节点接收指示UE上下文更新的完成的第二消息或指示UE上下文更新的失败的第三消息，以及基于第二消息或第三消息的接收确定是否向第二节点重发送第一消息。UE上下文更新的过程可以由请求在UE和第三节点之间执行的UE上下文更新的操作的消息从第二节点向第三节点的发送来启动。
根据本公开的另一个方面，提供了无线通信系统中的第二节点。第二节点包括收发器和至少一个处理器，处理器被配置为控制收发器从第一节点接收请求用户设备(UE)上下文更新的第一消息，以及响应于第一消息的接收向第三节点发送请求在第三节点和UE之间执行的UE上下文更新的操作的消息，确认基于向第三节点发送的消息而被启动的UE上下文更新的结果，以及基于确认的结果向第一节点发送指示UE上下文更新的完成的第二消息或指示UE上下文更新的失败的第三消息。
根据以下结合附图公开了本公开的各种实施例的详细描述，本公开的其他方面、优点和显著特征对于本领域技术人员将变得明显。
发明的有益效果
本公开的各方面将至少解决上述的问题和/或缺点并且至少提供下述优点。因此，本公开的一个方面将提供在非独立(NSA)结构中的若干节点之间高效地执行用户设备(UE)上下文的更新过程的方法。
另外的方面将在随后的描述中被部分地阐述，并且将部分地从描述中变得明显或者可以部分地通过所呈现的实施例的实践而获知。
附图说明
根据以下结合附图的描述，本公开的某些实施例的以上和其他方面、特征和优点将更加明显，其中：
图1是图示出根据本公开的实施例的多无线电接入技术(RAT)双连接结构的概念图；
图2是图示出根据本公开的实施例的节点和用户设备(UE)之间的连接的概念图；
图3是图示出根据本公开的实施例的在节点和UE中配置的协议栈的概念图；
图4是图示出根据本公开实施例的用于在节点之间控制UE的上下文的信令的流程图；
图5是图示出根据本公开的实施例的UE上下文的更新过程在各节点中失败的状况的示图；
图6a是用于描述根据本公开的实施例的当分布式单元(DU)连续触发UE上下文的更新时的信令的流程图；
图6b是用于描述根据本公开的实施例的当DU连续触发UE上下文的更新时的信令的流程图；
图7是图示出根据本公开的实施例的用于控制UE上下文的DU的操作的流程图；
图8是图示出根据本公开的实施例的用于控制UE上下文的中央单元(CU)的操作的流程图；
图9是用于描述根据本公开的实施例的在UE上下文的更新过程失败的各种情况下CU向DU发送根据本公开的实施例的拒绝消息的示例的流程图；
图10是用于描述根据本公开的实施例的在UE上下文的更新过程失败的各种情况下CU向DU发送根据本公开的实施例的拒绝消息的示例的流程图；
图11是用于描述根据本公开的实施例的在UE上下文的更新过程失败的各种情况下CU向DU发送根据本公开的实施例的拒绝消息的示例的流程图；
图12是用于描述根据本公开的实施例的在UE上下文的更新过程失败的各种情况下CU向DU发送根据本公开的实施例的拒绝消息的示例的流程图；
图13是用于描述根据本公开的实施例的在UE上下文的更新过程失败的各种情况下CU向DU发送根据本公开的实施例的拒绝消息的示例的流程图；
图14是图示出在根据本公开的实施例的给定状况下CU向DU发送根据本公开的实施例的拒绝消息的示例的示图；
图15是图示出在根据本公开的实施例的切换(handover)状况下CU向DU发送根据本公开的实施例的拒绝消息的示例的示图；
图16是图示出根据本公开的实施例的CU和DU已经被分离的基站执行UE上下文的更新的示例的示图；
图17是图示出根据本公开的实施例的基站的配置的示图；
图18是图示出根据本公开的实施例的UE的配置的示图；
图19是用于描述根据本公开的实施例的不使用UE上下文修改拒绝消息的实施例的示图；
图20是用于描述根据本公开的实施例的使用F1 UE上下文修改确认消息来通知UE上下文过程的失败的方法的流程图；
图21是用于描述根据本公开的实施例的通知UE上下文更新过程的失败、指示F1UE上下文确认修改消息中不包括RRC容器IE的方法的示图；
图22是用于描述根据本公开的实施例的用于在对UE上下文修改需要请求确认之后的改变的实施例的示图；和
图23是用于描述根据本公开的实施例的用于在对UE上下文修改需要请求确认之后的改变的实施例的示图。
贯穿附图的相似的附图标记将被理解为指代相似的部分、组件和结构。
具体实施方式
提供以下参考附图的描述以协助全面理解由权利要求及其等同物限定的本公开的各种实施例。其包括各种特定的细节以协助理解，但这些仅被视为示例性的。因此，本领域普通技术人员将认识到，在不脱离本公开的范围和精神的情况下，可以对本文描述的各种实施例做出各种改变和修改。此外，为了清楚和简洁，可以省略对已知的功能和结构的描述。
在以下的描述和权利要求中使用的术语和词语不限于书面含义，而仅由发明人使用以使得能够清楚且一致地理解本公开。因此，对于本领域技术人员来说明显的是，提供本公开的各种实施例的以下描述仅用于说明目的，而不是为了限制由所附权利要求及其等同物限定的本公开的目的。
应理解单数形式“一”和“所述”包括复数所指对象，除非上下文另有明确指定。因此，例如，对“部件表面”的引用包括对一个或多个这样的表面的引用。
在描述本公开时，如果认为对相关已知功能或配置的详细描述使本公开的主旨不必要地含糊，则将其省略。此外，下文将描述的术语已考虑本公开中的功能而被定义，并且取决于用户、操作者的意图或实践而可以不同。因此，每个术语应该基于整个说明书的内容来定义。
此外，在对本公开的实施例进行详细描述时，在不显著脱离本公开的范围的情况下，本发明的主要主旨可以被稍微修改并被应用于具有类似技术背景和信道形式的其他通信系统，这可以由具有本公开相应技术领域的熟练技术知识的人来确定。
根据结合附图详细描述的实施例，本公开的优点和特性以及实现这些优点和特性的方法将变得更加明显。然而，本公开不限于所公开的实施例，而是可以以各种不同的方式实施。提供实施例仅用于完成本公开，以及允许本领域技术人员充分理解本公开的范畴。本公开由权利要求的范畴限定。相同的附图标记将被用于指代贯穿附图的相同或相似的元素。
在本公开中，可以理解，流程图中的每个框以及流程图中的框的组合可以由计算机程序指令来执行。这些计算机程序指令可以安装在通用计算机、专用计算机或其他可编程数据处理装置的处理器上，以便由计算机或其他可编程数据处理装置的处理器执行的指令创建用于执行流程图框中指定的功能的方法。
这些计算机程序指令还可以存储在能够指导计算机或其他可编程数据处理设备以特定方式实现功能的计算机可用或计算机可读存储器中，使得存储在计算机可用或计算机可读存储器中的指令生成包括实施流程图框中指定的功能的指令方法(instructionmeans)的制品(article of manufacture)。
计算机程序指令还可以被加载到计算机或其他可编程数据处理装置上，使得一系列操作在计算机或其他可编程装置上执行以生成计算机执行进程，以便使计算机或其他可编程装置执行的指令提供用于执行流程图框中描述的功能的操作。
此外，流程图的每个框可代表模块、段或代码的部分，其包括用于实施指定逻辑功能的一个或多个可执行指令。还应该注意的是，在一些可替代的实施中，框中注明的功能可能出现乱序。例如，取决于所涉及的功能，连续示出的两个框实际上可以实质上同时执行，或者这些框有时可以以相反的顺序执行。
本实施例中使用的术语“单元”是指软件或硬件组件，诸如现场可编程门阵列(FPGA)或专用集成电路(ASIC)，并且“单元”执行特定任务。“单元”可以有利地被配置为驻留(reside)在可寻址存储介质上并且被配置为在一个或多个处理器上操作。
因此，“单元”可以包括例如组件，诸如软件组件、面向对象的软件组件、类组件和任务组件、进程、功能、属性、过程、子例程、程序代码段、驱动程序、固件、微码、电路、数据、数据库、数据结构、表格、数组和变量。在组件和“单元”中提供的功能可以被组合成更少的组件和“单元”，或者可以被进一步分离成另外的组件和“单元”。此外，组件和“单元”可以被实施为在设备或安全多媒体卡(security multimedia card)内的一个或多个中央处理单元(CPU)上操作。
在下文中，将参考附图更具体地描述根据本公开的实施例的在节点之间高效地执行用于对在多无线电接入技术(RAT)之间的DC结构中的用户设备(UE)上下文的控制的信令的方法。
图1是示出了根据本公开的实施例的多RAT双连接结构的概念图。
参照图1，用于描述本公开的实施例的用于EN-DC的结构可以被配置为如图1所示。
更具体地，根据本公开的实施例的用于EN-DC的连接结构可以是长期演进(LTE)基站11(即主eNB)锚定NR的控制平面(C-plane)信令、NR基站12被配置为辅eNB并且每个基站使用演进分组核心(EPC)1作为核心网的结构。
根据本公开的实施例的UE 100可以使用LTE基站11作为主eNB和NR基站12作为辅eNB通过双连接接入每个基站。
图2是图示出根据本公开的实施例的节点和UE之间的连接的概念图。
图3是图示出根据本公开的实施例的被配置在节点和UE中的协议栈的概念图。
参照图2，根据本公开的实施例的NR基站可以由将包括在一个基站中的协议栈针对每个功能进行分离并将协议栈分离为中央单元(CU)和分布式单元(DU)来配置。在这种情况下，CU和DU可以实施为分开的基站，并且可以执行基站的各自的操作。在以下实施例中，CU和DU可以被描述为基站、单元或节点。
图2图示了根据本公开的实施例的UE 200已经接入LTE基站(RAT#1)21和被分离成CU基站(RAT#2-CU)22b和DU基站(RAT#2-DU)22a的NR基站22的状态。
参照图2，LTE基站21和NR基站22的CU 22b可以通过X2接口(RAT#1-RAT#2-I/F)被连接。NR基站22的CU 22b和NR基站22的DU22a可以通过前传接口(fronthaul interface)(RAT#2-CU-DU-I/F)被连接。以下，为了描述的方便，将CU基站描述为CU，将DU基站描述为DU。
更详细的协议栈在图3中被示出。
参照图3，在LTE基站31中，无线电资源控制(RRC)层、分组数据汇聚协议(PDCP)层、无线电链路控制(RLC)层、媒体访问控制(MAC)层、物理(PHY)层和射频(RF)层的所有功能可以被实施并且可以操作。
相反，在NR基站32中，可以基于各自的功能来分离协议层。RRC层和PDCP层可以被配置为CU 32b，并且RLC层、MAC层、PHY层和RF功能可以被配置为DU 32a。即，CU 32b可以执行与RRC层和PDCP层相应的功能，并且DU 32a可以执行RLC层、MAC层、PHY层和RF的功能。
根据本公开的实施例，配置与LTE基站31和NR基站32的双连接的UE300的所有协议栈都可以像LTE基站31一样被包括和实现。
各层的功能简述如下。PDCP层负责诸如IP头部压缩/重构的操作。RLC层以适当的大小重配置PDCP分组数据单元(PDU)。MAC层被连接到若干RLC层，并执行将RLC PDU复用(multiplex)为MAC PDU和从MAC PDU分用(demultiplex)为RLC PDU的操作。PHY层执行对更高层数据执行信道编码和调制、将数据生成为OFDM符号、向无线电信道发送OFDM符号或解调通过无线电信道接收的OFDM符号、将符号进行信道解码和将其向更高层发送的操作。此外，PHY层与MAC层一起使用混合自动重复查询(hybrid automatic repeat query，HARQ)进行纠错(error correction)。接收阶段(receiving stage)发送指示是否已经接收由发送阶段(transmitting stage)发送的数据包的1比特(bit)。这被称为HARQ ACK/NACK信息。RRC层仅在控制平面中被定义。RRC层负责控制与无线电承载的配置、重配置和释放相关的其他信道。
如果将协议层针对NR基站32中的每个功能进行分离并且如上所述地实施为DU32a和CU 32b，则在通过EN-DC与UE 300的连接中，根据与UE300的无线通信来执行信令的节点的数量可以是3个或更多。这可能意味着与UE相关的给定操作被触发或者在控制用于UE的给定操作中可以涉及三个或更多节点。
例如，用于每个小区的测量值、调度信息(scheduling information)、天线信息或波束特性信息(beam characteristic information)是与RF或MAC层或PHY层相关的参数，并且可能需要针对每个UE进行控制。如果这些参数的改变是必要的，则RF或MAC层或PHY层可以向RRC层执行与参数改变相关的报告，以便在RRC层中生成包括该参数的RRC消息。在这种情况下，在本公开提出的将NR基站分为CU和DU的状况下，DU需要向CU发送请求参数改变的消息。
如果如上所述用于参数改变的信令被从DU向CU发送，则CU可以向LTE基站发送请求参数改变的消息。LTE基站可以通过与UE的无线通信来执行用于参数改变的操作。
如果如上所述与参数相关的UE上下文的更新是必要的，则需要在LTE基站与CU和DU的三个节点之间发送和接收相应的信令。即，用于控制UE上下文的通信过程在若干节点之间执行。因此，可能出现资源浪费或通信过程管理效率低下的问题。
在下文中，为了描述的方便，NR基站的DU和第一节点、NR基站的CU和第二节点、LTE基站和第三节点可以互换使用。
参考图4、图5、图6A和图6B，更详细的示例被描述。
图4是图示出根据本公开的实施例的用于在节点之间控制UE的上下文的信令的流程图。
图5是图示出根据本公开的实施例的UE上下文的更新过程在各节点中失败的状况的示图。
图6A和图6B是用于描述根据本公开的各种实施例的当DU连续触发UE上下文的更新时的信令的流程图。
参照图4，如果确定UE上下文的更新是必要的，则第一节点(gNB-DU)42a可以向第二节点(gNB-CU)42b发送请求UE上下文的修改(UE上下文修改需要)的消息(S401)。
在这种情况下，请求UE上下文的修改的UE上下文修改需要消息可以包括例如以下信息。
[表格1]
Figure BDA0003211518180000101
已经从第一节点42a接收请求UE上下文的修改的消息的第二节点42b可以向第一节点42a发送相应的确认消息(F1 UE上下文修改确认)(S402)。此外，响应于从第一节点42a接收的用于UE上下文的修改的请求，第二节点42b可以通过X2接口向第三节点(MeNB)41发送请求UE上下文的更新的消息(X2 SGNB修改需要)(S403)。
第三节点41可以基于从第二节点42b接收的UE上下文请求消息(X2SGNB修改需要)执行用于UE 400的上下文更新过程。例如，如图4所示，第三节点41可以向UE 400发送用于UE上下文的更新的RRC消息(RRC ConnReconfiguration)(S404)。
UE 400可以基于从第三节点41接收的无线电资源控制(RRC)消息中包括的信息执行更新UE 400的上下文的操作。当上下文更新完成时，UE 400可以向第三节点41发送包含相应信息的RRC消息(RRC ConnReconfiguration)(S405)。
已经从UE 400接收RRC连接重配置完成(RRC ConnReconfiguration完成)消息的第三节点41可以通过X2接口向第二节点42b发送从UE接收的RRC连接重配置完成(RRCConnReconfiguration完成)消息中包括的信息(S406)。
已经从第三节点41接收包括关于UE上下文的更新(X2 SGNB修改确认)的信息的消息的第二节点42b可以基于该信息执行改变UE的上下文的过程(S407)。
在执行这样的过程中，尽管UE上下文的更新已经由第一节点42a触发，然而指示UE上下文的过程是否已经被正确地执行的结果不会被向第一节点42a发送。换言之，当从第一节点42a接收的UE上下文修改需要消息被接收时，无论UE 400的上下文更新过程是否已经被完成或者是否已经被正确地执行，第二节点42b都执行向第一节点42a发送UE上下文修改确认消息的操作以通知UE上下文修改需要消息已经成功地被接收。
例如，UE上下文修改确认消息可以在告知已收到(ACK)的意义上被从第二节点42b向第一节点42a发送，告知已收到(ACK)为在UE 400的上下文的更新过程被执行的同时或者在UE 400的上下文的更新过程完成之后，通知从第一节点42a接收的消息在用于UE 400的上下文的更新过程的开始之前仅仅已经被成功地接收。即，UE上下文修改确认消息可以通过图4中虚线所指示的箭头(S402-①、②和③)中的任何一个来被发送。
如上所述，因为无论UE上下文的实质更新是否已经完成，UE上下文修改确认消息都被从第二节点42b向第一节点42a发送，所以第一节点42a无法确认UE的上下文是否已经被成功地更新。特别是，UE上下文的更新过程如上所述通过多个节点之间的信令来执行。因此，如果出现诸如在任何一个节点中或用于任何一个信令的发送和接收的失败的异常状况，则会出现问题。
参照图5，第一节点52a可以向第二节点52b发送用于UE上下文的更新的消息(UE上下文需要修改)(S501)。响应于此，第二节点52b可以向第一节点52a发送用于UE上下文更新的确认消息(UE上下文修改确认)(S502)。
参照图5，在基于从第一节点52a接收的消息启动UE上下文的更新过程的操作中，第二节点52b中可能出现错误(S510)。因此，可能会出现UE上下文的更新过程没被启动的异常状况。
相反，第二节点52b可以基于从第一节点52a接收的消息启动UE上下文的更新过程，并且可以向第三节点51发送请求UE上下文的更新的消息(X2 SGNB需要修改)(S503)。在这种情况下，可能发生异常状况，其中，请求上下文更新的RRC消息由于发生在第三节点51中的给定错误而没有被向UE 500发送(S520)并且UE上下文的更新过程在更新过程中以失败结束。
又例如，第三节点51可以基于从第二节点52b接收的用于UE上下文的更新请求消息(X2 SGNB修改需要)向UE 500发送用于执行上下文更新过程的RRC消息(S504)。在这种情况下，在UE 500中的RRC消息的接收和处理可能会失败或者可能出现异常状况，其中，因为无线通信的原因所导致发生的错误，UE上下文的更新过程的执行以失败结束(S530)。
又例如，UE 500可以基于从第三节点51接收的RRC消息正常地执行上下文更新操作，并且可以向第三节点51发送相应的完成消息(RRC ConnReconfiguration完成)(S505)。在这种情况下，在第三节点51中可能出现RRC连接重配置完成消息的接收失败的错误(S540)。因此，可能出现UE上下文的更新过程的执行以失败结束的异常状况。
又例如，在第三节点51从UE 500接收通知UE上下文的更新过程已经完成的消息(RRC ConnReconfiguration完成)之后，其通过X2接口向第二节点52b发送通知UE上下文的更新的完成的消息(X2 SGNB修改确认)(S506)。然而，在第二节点52b中可能出现UE上下文的更新过程由于给定错误而以失败结束的异常状况(S550)。
如果如上所述在UE已经通过EN-DC连接接入LTE基站和NR基站的状态下，NR基站被分离为CU节点和DU节点，那么一旦涉及执行与UE相关的给定操作的三个或更多节点导致了资源分配失败、发送或接收错误或者接收信息处理中的错误的出现，给定操作的执行中就会出现问题。
如上所述，任一节点中的处理失败或者两个节点之间任一信令的发送或接收失败，UE上下文的更新过程可以不被执行。如果由第一节点触发的用于UE上下文的更新的请求没有被正确执行，则第一节点必须再次触发请求。然而，在这种情况下，第一节点不会从第二节点接收任何指示UE上下文的更新已经失败的信息。因此，存在的问题是第一节点无法执行关于因为请求的UE上下文的修改已经失败所以第一节点必须再次发送相应的重请求消息的任何操作，或者是第一节点必须重复发送多少重请求消息。
在第一节点中，用于UE上下文的更新的请求可以被多次触发。例如，第一节点可以因为与从UE接收的波束特性信息相关的参数的改变是必要的而触发第一上下文请求消息的发送，并且之后可以因为用于UE的切换的测量参数的改变是必要的而触发第二上下文请求消息的发送。如果如上所述用于不同参数信息的更新请求被连续触发，则可能由于相应的信令在若干节点之间被发送而出现问题。
参照图6A，当第一节点62a确定UE上下文的更新是必要的时，其可以向第二节点62b发送请求UE上下文的更新的消息(UE上下文修改需要-第一需要)(S601)。第二节点62b可以响应于从第一节点62a接收的UE上下文修改需要消息而向第一节点62a发送确认消息(UE上下文修改确认)(S602)，并且之后可以启动用于UE 600的上下文更新过程。
在第一节点62a向第二节点62b发送UE上下文更新请求消息之后(S601)，当确定与已经请求更新的上下文不同的参数改变是必要的时，第一节点62a可以向第二节点62b发送请求改变另一个参数的消息(UE上下文修改需要-第二需要)(S603)。在第二节点62b响应于第二上下文更新请求而发送确认消息(UE上下文修改确认)之后(S604)，其可以启动用于UE600的上下文更新过程。
当用于UE 600的上下文更新过程被启动时，第二节点62b可以向第三节点61发送请求UE上下文的更新的消息(X2 SGNB修改需要)(S605)。响应于此，第三节点61可以向UE600发送用于上下文更新的RRC消息(RRC重配置)(S606)。如果用于上下文更新的操作在UE600中被执行并且更新被完成，则UE 600向第三节点61发送包括相应信息的RRC消息(RRC重配置完成)(S607)。已经接收RRC消息的第三节点61可以向第二节点62b发送消息(X2 SGNB修改确认)以便通知UE上下文的更新的完成(S608)。
已经从第三节点61接收指示UE上下文的更新已经完成的信息的第二节点62b可以基于该信息向第一节点62a发送包括指示更新已经完成的指示符(完成指示符)的消息(UE上下文修改请求)以请求UE上下文的更新(S609)。
在这种情况下，完成指示符是通知与UE的上下文相关的参数信息已经被更新的指示符，并且不包括关于UE的已更新上下文与哪个参数相关的信息。此外，与UE的上下文的更新相关的内容被包括在RRC容器中，并且通过UE上下文修改请求消息被从第二节点向第一节点发送，但是第二节点无法确认UE上下文的更新是否已经被完成，因为它只执行将包括在RRC容器中的信息向UE发送的功能，而不分析该信息。
因此，问题发生在当第一节点在做出两次上下文更新请求之后接收这样的完成指示符时，第一节点不知道该完成指示符指示的更新完成用于两次上下文请求中的哪个参数信息。即，已经接收完成指示符的第一节点不知道第一上下文更新请求和第二上下文更新请求中的一个所请求的上下文的更新是否已经完成。因此，存在的问题是第一节点无法确定是再次发送请求第一上下文更新的消息还是再次发送请求第二上下文更新的消息。
参照图6B，当确定UE的上下文的更新是必要的时，第一节点62a可以向第二节点62b发送请求上下文的更新的消息(UE上下文修改需要-第一需要)(S611)。响应于此，第二节点62b可以向第一节点62a发送确认消息(UE上下文修改确认)(S612)。此外，当确定与根据请求(S611)的参数信息不同的参数信息的更新是有必要的时，第一节点62a可以另外地向第二节点62b发送UE上下文更新请求消息(UE上下文需要修改-第二需要)(S613)。响应于此，第二节点62b可以向第一节点62a发送确认消息(UE上下文修改确认)(S614)。
已经从第一节点62a接收用于UE上下文的更新的请求的第二节点62b可以向第三节点61发送请求UE上下文的更新的消息。在这种情况下，如图6B所示，从第二节点62b向第三节点61发送的、用于UE上下文的更新请求消息(X2 SGNB修改需要)可以针对由第一节点62a触发的每个请求而被向第三节点61发送(S615、S616)。
第三节点61可以根据从第二节点62b接收的用于UE上下文的更新的请求向UE 600发送RRC消息(RRC重配置)。同样地，每个RRC消息可以响应于从第二节点62b接收的每个UE上下文更新请求消息(X2 SGNB修改需要)而被发送(S617、S618)。UE 600可以基于从第三节点61接收的RRC消息执行UE上下文的更新操作，并且可以向第三节点61发送相应的完成消息(RRC重配置完成)(S619、S620)。
第三节点61可以响应于从UE 600接收的每个RRC重配置完成消息向第二节点62b发送通知上下文更新的完成的消息(X2 SGNB更新确认)(S621、S622)。响应于该消息的接收，第二节点62b可以向第一节点62a发送包括用于UE上下文的更新的完成的指示符(完成指示符)的消息(UE上下文修改请求)(S623、S625)。
虽然由第一节点62a第一触发的UE上下文更新请求和由第一节点62a第二触发的UE上下文更新请求是被顺序执行的，但是根据第一触发UE上下文更新请求的更新过程可以晚于根据第二触发UE上下文更新请求的更新过程。
如果出现如图6B这种状况，虽然第一节点62a从第二节点62b接收了通知UE上下文的更新已经被完成的第一消息(S623)，但是由于消息中包含的完成指示符没通知更新是用于哪个参数信息，第一节点无法知道相应的消息是与第一请求有关或是与第二请求有关。
因此，如图6B中所示，第一节点62a即使在其已经向第二节点62b发送针对从第二节点62b接收的消息(UE上下文修改请求)的响应消息(UE上下文修改响应)之后也无法知道哪个UE上下文已经被更新(S624)。此外，如图6B所示，虽然通知UE上下文的更新的完成的消息(UE上下文修改请求)从第二节点被接收(S625)，但是第一节点无法知道这样的消息是与第一请求相关或是与第二请求相关。
即，在第一节点62a若干次发送请求UE上下文的更新的消息之后，虽然指示上下文更新已经被完成的信息被响应于消息地从第二节点62b接收，但是存在的问题是第一节点无法知道与若干请求消息中的哪一个请求消息相应的上下文已被更新。
特别地，如以上关于图5所描述的，如果与多个节点中的任何一个相关的UE上下文的更新过程失败，则不知道多个请求中的哪一个已经失败以及请求的哪个上下文已经被更新。因此，存在的问题是无法明确第一节点的后续操作(例如，关于是否再次发送请求上下文的已失败更新的消息的操作)。
因此，本公开提出了用于在配置有CU和DU的NR基站和LTE基站已经通过EN-DC结构连接到UE的状态下有效地执行用于控制UE上下文的信令的实施例。
更具体地，本公开的实施例提出了在UE上下文的更新过程没被正常执行的情况下向DU发送相应信息的方法。
此外，本公开的实施例提出了用于在UE上下文的更新已经基于对UE上下文的更新的请求而完成的情况下，DU确认关于哪个上下文的更新已经被完成的信息的方法。
在本发明的第一实施例中，通过DU和CU之间的接口发送的UE上下文修改拒绝消息被定义，以便DU被通知关于UE上下文的更新的失败的信息。
在这种情况下，UE上下文修改拒绝消息是通过CU和DU之间的接口发送的消息，目的是通知DU在CU从DU接收用于UE上下文的请求消息之后、UE上下文的更新过程被启动时可能发生异常状况。即，根据本公开的实施例的UE上下文修改拒绝消息在确定UE上下文的更新过程由于根据图5中所描述的各种示例的给定原因已经失败的情况下，可以是通知DU上下文更新过程的执行已经失败的消息。
这样的UE上下文修改拒绝消息可以已经包括各种类型的信息。例如，UE上下文修改拒绝消息可以包括关于在上下文更新中已经失败的UE的信息(例如，UE的ID，即用于CU的UE的ID和用于DU的UE的ID)以及关于将被向UE发送的RRC容器的信息。此外，UE上下文修改拒绝消息还可以包括关于已经接收UE上下文修改拒绝消息的DU能够再次请求已经更新失败的UE上下文的更新的时间(等待时间)的信息以及诸如对同一上下文的请求可能有多少的计数(重试计数)信息。此外，UE上下文修改拒绝消息可以包括关于UE上下文的更新的失败原因的信息(关于拒绝UE上下文修改需要的原因的信息)。
更具体地，根据本公开的实施例的可以包括在UE上下文修改拒绝消息中的信息可以总结如下表。
[表格2]
Figure BDA0003211518180000161
Figure BDA0003211518180000171
图7是图示出根据本公开的实施例的用于控制UE上下文的DU的操作的流程图。
图8是图示出根据本公开的实施例的用于控制UE上下文的CU的操作的流程图。
参照图7，根据本公开的实施例的第一节点(DU)可以在执行与UE无线通信的同时根据通信检测用于某些参数的更新的需要。例如，根据本公开的实施例的第一节点基于与UE无线通信的结果，可以确定与用于UE中配置的小区的测量值相关的参数改变是必要的，或者可以确定与用于每个小区的波束特性信息相关的参数改变是必要的。
如上所述，第一节点可以向包括RRC层的第二节点(CU)报告已经确定改变是必要的至少一个参数。即，第一节点可以发送第一消息以请求与已经确定改变是必要的参数相关的UE上下文的更新(S710)。
在这种情况下，第一消息可以是通过连接在第一节点和第二节点之间的前传接口发送的UE上下文修改需要消息。相应的消息可以包括表格1中的若干条信息。
在如上所述发送第一消息之后，根据本公开的实施例的第一节点可以响应于第一消息的发送来确认哪条消息从第二节点被接收(S720)。
例如，第一节点可以响应于第一消息的发送，从第二节点接收指示UE上下文的更新的完成的第二消息。在这种情况下，指示UE上下文的更新的完成的第二消息可以是例如通过前传接口被发送的UE上下文修改请求消息。
根据本公开的实施例的第二消息可以包括指示如以上关于图6A和图6B所描述的用于被请求UE上下文的更新完成的信息(例如，完成指示符)。即，根据本公开的实施例的第二消息可以包括关于UE的信息或者诸如在用于多个UE的多个UE上下文更新请求已经被做出的情况下，哪个UE上下文已经被更新的信息。
当如上所述的第二消息被接收时，根据本公开的实施例的第一节点可以基于已经完成更新的UE上下文来执行与UE的无线通信(S730)。
此外，例如，第一节点可以响应于第一消息的发送，从第二节点接收指示UE上下文的更新失败的第三消息。在这种情况下，指示UE上下文的更新的失败的第三消息可以是例如通过前传接口发送的UE上下文修改拒绝消息。
根据本公开的实施例的第三消息可以包括关于在UE和第二节点和第三节点之间执行的更新UE上下文的过程期间，相应过程由于什么原因导致、在哪个节点失败的信息。例如，第三消息可以包括诸如在用于启动UE上下文的更新过程的UE上下文的更新请求消息从第二节点向第三节点发送之后，第三节点已经在相应的过程中失败的信息，或者诸如已经从第三节点接收UE上下文的更新过程的指示的UE在执行相应上下文的更新时，已经在相应过程中失败的信息。
此外，根据本公开的实施例的第三消息可以包括如上所述的表格2中的若干条信息。即，第三消息中可以包括用于第一节点和第二节点的UE的ID，或者诸如用于请求相应UE上下文的更新的第一消息可以被发送于什么时候以及被发送多少次的信息。
当第三消息被接收时，根据本公开的实施例的第一节点可以基于第三消息中包括的信息再次向第二节点发送用于请求UE上下文的更新的第一消息(S740)。
参照图8，根据本公开的实施例的第二节点(CU)可以从第一节点(DU)接收请求UE上下文的更新的第一消息(S810)。
当第一消息被接收时，根据本公开的实施例的第二节点可以启动UE上下文的更新过程。例如，根据本公开的实施例的第二节点可以向第三节点发送请求在第三节点与UE之间的UE上下文的更新操作的执行的消息(S820)。
当如上所述从第二节点向第三节点发送消息时，第三节点可以在第三节点与UE之间执行UE上下文的更新操作。例如，第三节点可以使用RRC消息指示用于UE的UE上下文的更新操作。UE可以基于指示执行UE上下文的更新操作。此外，作为响应，UE可以向第三节点发送包括相应结果信息的RRC消息。
第三节点可以向第二节点发送用于第三节点与UE之间的UE上下文的更新操作的结果信息。例如，如果UE上下文的更新操作由于给定原因导致在第三节点或UE中失败，则第三节点可以通过X2接口向第二节点发送包括相应信息的消息(拒绝消息)。此外，当UE上下文的更新操作被成功地完成时，第三节点可以通过X2接口向第二节点发送包括相应信息的消息(确认消息)。
在启动UE上下文的更新过程之后，根据本公开的实施例的第二节点可以基于从第三节点接收的消息来确认UE上下文的更新过程的结果(S830)。
例如，当UE上下文的更新的完成基于从第三节点接收的确认消息而被确认时，第二节点可以向第一节点发送请求相应UE上下文的更新的第二消息(S840)。在这种情况下，第二消息可以是通过第一节点和第二节点之间的前传接口发送的UE上下文修改请求消息。
又例如，当UE上下文的更新的失败基于从第三节点接收的拒绝消息而被确认时，第二节点可以向第一节点发送通知相应的UE上下文的更新的失败的第三消息(S850)。在这种情况下，第三消息可以是通过前传接口发送的UE上下文修改拒绝消息，包括第三节点接收的信息或者在相应UE上下文的更新由于给定原因在第二节点中失败的情况下的相应信息。
如上所述，在UE上下文的更新被请求之后，根据本公开的实施例的DU能够基于从CU接收的消息中所包括的信息快速确定是否再次请求启动相应UE上下文的更新过程，或者能够基于已更新的上下文快速确定DU是否必须执行与UE的无线通信。特别地，如果UE上下文的更新已经被成功地完成，则根据本公开的实施例的CU发送诸如哪个UE上下文的更新已经被完成的信息，并且如果UE上下文的更新已经失败，则向DU提供失败原因以及与用于恢复失败的操作相关的信息。因此，存在的效果是UE上下文的更新过程可以被无延迟地更高效地执行。
图9至图13是用于描述根据本公开的实施例的在UE上下文的更新过程失败的各种情况下CU向DU发送根据本公开的实施例的拒绝消息的示例的流程图。
参照图9，当UE上下文的更新被确定是必要的时，第一节点92a可以向第二节点92b发送请求UE上下文的更新的消息(UE上下文修改需要)(S901)。当消息从第一节点92a被接收时，第二节点92b可以基于接收的消息启动UE上下文的更新过程。供参考，图9还图示了第三节点91和UE 900。
参照图9，在用于第二节点92b启动UE上下文更新过程的操作中可能发生异常状况。例如，UE上下文的更新过程可能由于诸如第二节点92b从第一节点92a接收UE上下文修改需要消息失败的问题而没被启动。
如果如上所述UE上下文的更新过程没被启动，则根据本公开的实施例的第二节点92b可以向第一节点92a发送UE上下文修改拒绝消息以便通知第一节点92a UE上下文的更新过程还没被启动(S902)。例如，UE上下文修改拒绝消息可以包括关于归咎于第二节点92b中的接收失败的UE上下文过程失败的信息。
已经接收如上所述的拒绝消息的第一节点92a可以快速确认从第二节点92b请求的过程已经失败。因此，第一节点可以随后再次向第二节点92b发送用于同一上下文的更新请求。
参照图10，当UE上下文的更新被确定是必要的时，第一节点102a可以向第二节点102b发送请求UE上下文的更新的消息(UE上下文修改需要)(S1001)。当从第一节点102a接收消息时，第二节点102b可以基于接收的消息启动UE上下文的更新过程。即，第二节点102b可以基于从第一节点102a接收的请求消息向第三节点101发送请求UE上下文的更新的消息(X2UE上下文修改需要)(S1002)。
如图10所示，响应于从第二节点102b接收的UE上下文更新请求，第三节点101需要向UE 1000发送用于上下文更新的执行的RRC消息，但在相应操作的执行之前可能发生异常状况。例如，诸如第三节点101在X2 SGNB修改需要消息的接收中失败的问题或者没向UE1000发送相应的RRC消息的问题可能发生。
在这种情况下，第三节点101可以通过X2接口向第二节点102b发送通知UE上下文的更新过程已经失败的消息(X2 SGNB修改拒绝)(S1003)。
响应于此，已经从第三节点101接收包括关于UE上下文的更新的失败的信息的消息的第二节点102b可以向第一节点102a发送根据本公开的实施例的拒绝消息(S1004)。第一节点102a可以基于从第二节点102b接收的拒绝消息来确定是否再次发送请求相应上下文的更新的消息。例如，在给定时间(等待时间)到期之后，第一节点102a可以基于拒绝消息向第二节点102b发送请求上下文的更新的消息。
参照图11，当UE上下文的更新被确定是必要的时，第一节点112a可以向第二节点112b发送请求UE上下文的更新的消息(UE上下文修改需要)(S1101)。当从第一节点112a接收消息时，第二节点112b可以基于接收的消息向第三节点111发送请求UE上下文的更新的消息(X2 SGNB修改需要)(S1102)。
第三节点111可以响应于从第二节点112b接收的UE上下文更新请求向UE 1100发送用于执行上下文更新的RRC消息(S1103)。UE 1100可以基于从第三节点111接收的RRC消息启动用于更新上下文的操作。在这种情况下，由于诸如无线通信状况的原因，RRC消息的接收可能失败或者上下文更新过程可能失败。
在这种情况下，UE 1100向第三节点111发送用于第三节点111的连接重配置的RRC消息(RRC连接重配置请求)(S1104)。响应于此，UE 1100基于从第三节点111接收的消息(RRC ConnReestablishment)重配置与第三节点111的RRC连接(S1105)。当RRC连接被重配置时，UE 1100可以向第三节点111发送通知RRC连接重配置完成的消息(RRCConnReestablishment)(S1106)。
在这种情况下，UE 1100已经如上所述重配置了与第三节点111的RRC连接，但是还没有执行由第一节点112a触发的UE上下文的更新操作。因此，在第三节点111接收用于RRC连接的重配置完成消息之后，它可以向第二节点112b发送通知UE上下文的更新已经失败的消息(X2 SGNB修改拒绝)(S1107)。
响应于此，第二节点112b可以向第一节点112a发送通知UE上下文的更新的失败的消息(UE上下文修改拒绝)(S1108)。当从第二节点112b接收拒绝消息时，根据本公开的实施例的第一节点112a基于拒绝消息确定是否再次请求上下文更新。例如，第一节点112a可以基于拒绝消息中包括的用于对应上下文的更新失败计数和重试计数信息之间的比较来确定是否再次执行请求对应上下文的更新的消息的发送。
参照图12，当UE上下文的更新被确定是必要的时，第一节点122a可以向第二节点122b发送请求UE上下文的更新的消息(UE上下文修改需要)(S1201)。当从第一节点122a接收消息时，第二节点122b可以向第三节点121发送请求UE上下文的更新的消息(X2 SGNB修改需要)(S1202)。第三节点121可以响应于从第二节点122b接收的UE上下文更新请求向UE1200发送用于上下文更新的执行的RRC消息(S1203)。UE 1200可以基于从第三节点121接收的RRC消息启动用于更新上下文的操作。此外，当上下文更新操作被完成时，UE 1200可以向第三节点121发送包括相应信息的RRC消息(RRC ConnReconfiguration完成)(S1204)。
当第三节点121基于从UE 1200接收的RRC消息执行用于通知第二节点122b UE上下文的更新的完成的操作时可能发生异常状况。在这种情况下，第三节点121可以向第二节点122b发送包括指示UE上下文的更新已经失败的信息的拒绝消息(X2SGNB修改拒绝)(S1205)。
如上所述已经从第三节点121接收X2 SGNB修改拒绝的第二节点122b可以向第一节点122a发送通知UE上下文的更新已经失败的消息(UE上下文修改拒绝)(S1206)。第一节点122a可以基于接收的消息确定是否重发送请求UE上下文的更新的消息。
参照图13，当UE上下文的更新被确定是必要的时，第一节点132a可以向第二节点132b发送请求UE上下文的更新的消息(UE上下文修改需要)(S1301)。当从第一节点132a接收消息时，第二节点132b可以基于接收的消息向第三节点131发送请求UE上下文的更新的消息(X2 SGNB修改需要)(S1302)。
第三节点131可以响应于从第二节点132b接收的UE上下文更新请求向UE 1300发送用于上下文更新的执行的RRC消息(S1303)。UE 1300可以基于从第三节点131接收的RRC消息启动用于更新上下文的操作。此外，当上下文更新操作被完成时，UE 1300可以向第三节点131发送包括相应信息的RRC消息(RRC ConnReconfiguration完成)(S1304)。
第三节点131可以基于从UE 1300接收的RRC消息向第二节点132b发送用于通知UE上下文的更新的完成的消息(X2 SGNB修改确认)(S1305)。在这种情况下，可能发生诸如尽管第二节点132b已经接收了消息但由于给定原因导致的UE上下文的更新过程的执行的失败或更新过程的不可能执行的状况。
在这种情况下，第二节点132b可以向第一节点132a发送通知UE上下文的更新过程的失败的消息(UE上下文修改拒绝)(S1306)。此外，第二节点132b可以向第三节点131发送包括指示由于相应上下文更新的失败导致的相应上下文更新过程的取消的回滚指示符的消息(X2 SGNB修改需要)(S1307)。
第三节点131可以基于X2 SGNB修改需要消息向UE 1300发送包括用于将已更新对应上下文回滚的信息的RRC消息(S1308)。在执行用于将UE上下文回滚的操作之后，UE 1300可以向第三节点发送通知相应完成的消息(RRC ConnReconfiguration)(S1309)。
当从UE接收RRC ConnReconfiguration完成消息时，第三节点131可以向第二节点132b发送包括相应信息的消息(X2 SGNB修改确认)(S1310)。
在图9至图13中，除了与用于任何一个节点的UE上下文过程的失败所造成的拒绝消息的发送相关的实施例之外，拒绝消息还可以用于各种原因。
例如，如果在执行用于给定UE的切换过程的同时从DU接收了关于同一个UE的UE上下文修改需要消息，那么CU可以使用UE上下文修改拒绝消息拒绝相应请求。又例如，虽然CU已经向DU发送了关于给定UE的UE上下文修改请求消息，但是如果DU再次发送UE上下文修改需要消息，那么CU可以基于预先处于进度中的、用于UE上下文修改请求的会话(session)使用UE上下文修改拒绝消息来拒绝相应请求。
尽管UE上下文的更新没有失败，但根据本公开的实施例的第二节点可以在给定状况下使用UE上下文修改拒绝消息来通知UE上下文的更新现在无法被执行。
图14和15是图示出在根据本公开的实施例的给定状况下CU向DU发送根据本公开的实施例的拒绝消息的示例的示图。
参照图14，当UE上下文的更新被确定是必要的时，根据本公开的实施例的第一节点142a可以向第二节点142b发送请求UE上下文的更新的消息(UE上下文修改需要-第一需要)(S1401)。第二节点142b可以向第一节点142a发送用于确认消息的接收的消息(UE上下文修改确认)(S1402)。此外，根据本公开的实施例的第二节点142b可以响应于该请求向第三节点141发送用于UE上下文的更新的消息(SGNB上下文修改需要-第一需要)(S1403)。
在第一请求之后，根据本公开的实施例的第一节点142a可以另外地向第二节点142b发送用于另一个UE上下文的请求(UE上下文修改需要-第二需要)(S1404)。响应于此，根据本公开的实施例的第二节点142b可以向第一节点142a发送拒绝消息(UE上下文修改拒绝)(S1405)。
即，不同于相关技术中只有接收的确认通过确认消息被简单地执行，根据本公开的实施例的第二节点142b在UE上下文的更新过程无法被启动的给定状况下会使用拒绝消息。因此，存在的效果是能够解决第一节点不知道UE上下文的更新过程是否处于进度中的模糊状况。
响应于UE上下文的第一请求，用于上下文更新的若干条信令在第三节点141和UE1400之间被发送和接收(S1406、S1407)。第三节点141可以根据信令向第二节点142b发送包括结果信息的消息(SGNB修改确认)(S1408)。第二节点142b可以基于该消息向第一节点142a发送包括指示UE上下文的更新已经被完成的信息(完成指示符)的消息(UE上下文修改请求)(S1409)。
参照图15，根据本公开的实施例的第二节点可以确定切换是必要的。以下将现有的第二节点称为第二源节点(second source node)，将作为切换的目标的第二节点称为第二目标节点(second target node)。
根据本公开的实施例的第二源节点152b可以向第三节点151发送用于切换过程触发的信令(SGNB改变需要)(S1501)。已经接收信令的第三节点151可以通过向第二目标节点152b’发送SGNB添加请求消息来触发新的呼叫建立过程(call setup procedure)(S1502)。当所有呼叫建立被完成时，根据本公开的实施例，第二目标节点152b’可以向第三节点151发送SGNB添加请求Ack消息(S1503)。
当SGNB添加请求Ack消息被接收时，第三节点151可以向UE 1500发送用于RRC重配置的信令(S1504)。响应于此，UE 1500可以向第三节点151发送RRC完成消息(S1505)，因此RRC重配置过程可以被执行。根据本公开的实施例的第三节点151响应于RRC重配置过程的完成向第二源节点152b发送SGNB改变确认消息(S1506)，并且向第二目标节点152b’发送SGNB重配置完成消息(S1507)。在这种情况下，在接收SGNB改变确认消息之后，因为由第一源节点管理的UE的所属SgNB被改变，第二源节点152b可以通过向第一节点152a发送包括完成指示符的UE上下文修改请求消息来请求必要的操作(S1510)。相应的必要操作包括向目标节点的数据转发(Data Forwarding)以及相应的源侧UE上下文释放。因此，用于相应UE的SgNB改变过程可以被完成。
根据本公开的实施例的第一节点152a可以在第一节点不知道第二源节点152b和第二目标节点152b’之间的切换状况的状态下发送请求UE上下文的更新的消息(UE上下文修改需要)(S1508)。在这种情况下，第二源节点152b可以确定在切换处于进度中的状态下UE上下文的更新是不可能的，并且可以向第一节点152a发送根据本公开的实施例的F1 UE上下文修改拒绝消息(S1509)。因此，第一节点152a可以确认UE上下文的更新不能被执行。
在附图中，已经描述了CU向DU发送通知UE的上下文更新过程的失败的拒绝消息的实施例。然而，根据本公开的实施例，CU可以发送通知UE的上下文过程的进度已经被暂停的消息。
例如，如果UE的上下文更新过程不能被执行，则根据本公开的实施例的CU可以向DU发送用于发送相应信息的UE上下文修改暂停消息。在这种情况下，DU能够知道直到从CU接收通知UE的上下文更新过程的进度(或恢复)的UE上下文修改恢复消息为止，相应上下文的更新已经被暂停。因此，虽然通知相应上下文的更新已经被成功完成的消息在给定时间内没被接收，但根据本公开的实施例的DU可以不执行分开的(separate)重请求。
图16是图示出根据本公开的实施例的CU和DU已经被分离的基站执行UE的上下文更新的示例的示图。
参照图16，根据本公开的实施例的NR基站(gNB)162可以基于由已经向NR基站162执行初始接入的UE 1600发送的物理随机接入信道(PRACH)来启动服务波束，并且可以向UE1600发送包括与和UE 1600的RRC连接相关的配置信息的RRC重配置消息(S1601)。此外，NR基站(gNB)162可以基于RRC重配置消息从UE 1600接收CSI报告信息(S1602)。在这种情况下，CSI报告信息可以包括同步信号块秩指示符(SSBRI)、参考信号接收功率(RSRP)等。
NR基站162可以基于从UE 1600接收的CSI报告信息来确定波束相关UE上下文(beam-related UE context)的修改是必要的。例如，根据本公开的实施例的NR基站162可以确定与表格3中所包括的参数相关的以及与MAC层的波束控制相关的UE上下文信息的修改。
[表格3]
Figure BDA0003211518180000251
Figure BDA0003211518180000261
Figure BDA0003211518180000271
Figure BDA0003211518180000281
Figure BDA0003211518180000291
Figure BDA0003211518180000301
根据本公开的实施例的NR基站162的DU可以向NR基站162的CU发送UE上下文修改请求消息，UE上下文修改请求消息包括用于属于表格3中包括的RRC IEs的参数中的给定参数的UE上下文信息，以及有必要通过与UE 1600的通信来进行更新的UE上下文信息。
例如，当与波束控制相关参数(beam control-related parameters)中的csi_ResourceConfig相关的UE上下文的更新被确定是必要的时，NR基站162的DU可以向NR基站162的CU发送相应的请求消息。此外，在请求消息被发送之后，如果与用于BM的CSI_ReportConfig相关的UE上下文的更新被确定是必要的，则NR基站162的DU可以独立于该请求消息地向NR基站162的CU发送请求相应的UE上下文的更新的消息。
根据本公开的实施例，如上所述从NR基站162的DU接收UE上下文更新请求的NR基站162的CU可以执行UE上下文更新过程。此外，NR基站162的CU可以向NR基站162的DU发送指示用于UE 1600的服务波束是否已经被改变的结果信息(S1603)。
参照图16，如果与用于UE 1600的服务波束相关的UE上下文更新被确认，则根据本公开的实施例的NR基站162可以根据基于UE1600的SSBRI反馈而更新的服务波束来执行与UE的无线通信。
例如，根据本公开的实施例的NR基站162可以基于更新的服务波束向UE 1600发送RRC重配置消息(S1604)或发送MAC控制元素(CE)(S1605)。
图17是图示出根据本公开的实施例的基站的配置的示图。
图18是图示出根据本公开的实施例的UE的配置的示图。
参照图17，根据本公开的实施例的基站可以包括NR基站的DU、NR基站的CU和LTE基站。
根据本公开的实施例的基站可以包括收发器1710、控制器1720(例如，至少一个处理器)和存储器1730。在本公开中，基站的控制器1720可以被定义为电路或专用集成电路或至少一个处理器。
首先，根据本公开的实施例的基站的收发器1710可以向另一个网络实体发送信号和从另一个网络实体接收信号。例如，收发器1710可以通过无线接口执行与诸如UE的外部设备的无线通信，或者可以使用给定接口单元1711执行与另一个基站或网络功能实体的通信。
例如，NR基站的CU的收发器1710的接口单元1711可以包括用于与NR基站的DU通信的前传接口单元，并且可以包括用于与LTE基站通信的X2接口单元。此外，例如，NR基站的DU的收发器1710的接口单元1711可以包括用于与NR基站的CU通信的前传接口单元。此外，例如，LTE基站的收发器1710的接口单元1711可以包括用于与NR基站的CU通信的X2接口单元。
根据本公开的实施例的基站的控制器1720可以控制根据本公开中提出的实施例的基站的整体操作。例如，控制器1720可以控制收发器1710和存储器1730执行根据附图中描述的实施例的操作。
更具体地，NR基站的DU的控制器1720可以通过与UE的通信来检测UE上下文的更新是否是必要的，并且可以控制收发器1710向NR基站的CU发送请求相应上下文更新的消息。又例如，NR基站的CU的控制器1720可以响应于从NR基站的DU接收的请求消息来启动UE上下文更新过程，并且可以控制收发器1710向NR基站的DU发送包括相应的信息的消息。又例如，LTE基站的控制器1720可以基于从NR基站接收的UE上下文更新请求与UE一起执行上下文更新过程，并且可以控制收发器1710向NR基站发送相应的结果。
根据本公开的实施例的基站的存储器1730可以存储通过收发器1710发送和接收的信息和通过控制器1720生成的信息中的至少一个信息。例如，NR基站的存储器1730可以存储CU和DU之间配置的前传接口的功能分离方法(function separation method)和用于各层的参数。
参照图18，根据本公开的实施例的UE可以包括收发器1810、控制器1820(例如，至少一个处理器)和存储器1830。在本公开中，UE的控制器1820可以被定义为电路或专用集成电路或至少一个处理器。
首先，根据本公开的实施例的UE的收发器1810可以向另一个网络实体发送信号和从另一个网络实体接收信号。例如，收发器1810可以通过无线电接口向外部设备或基站发送无线电信号和从外部设备或基站接收无线电信号。
此外，根据本公开的实施例的UE的控制器1820可以控制根据本公开中提出的实施例的UE的整体操作。例如，控制器1820可以基于从基站接收的RRC消息来控制执行UE上下文更新操作。
此外，根据本公开的实施例的UE的存储器1830可以存储通过收发器1810发送和接收的信息以及通过控制器1820生成的信息。
不同于图14和图15中描述的拒绝消息被发送的情况，根据本公开的另一个实施例，通过发送F1 UE上下文确认消息而不使用F1 UE上下文拒绝修改消息来通知F1 UE上下文修改需要/确认过程的失败的方法可以被使用。
图19是用于描述根据本公开的实施例的不使用UE上下文修改拒绝消息的实施例的示图。
参照图19，在向CU发送UE上下文修改需要之后，根据本公开的实施例的DU驱动用于消息的发送的定时器。接收相应的消息后，CU向eNB发送X2 SGNB修改需要然后驱动定时器。如果RRC重配置过程由于给定原因(例如，UE侧过程失败)而失败，则eNB在定时器到期后向CU发送X2SGNB修改拒绝。
已经接收X2 SGNB修改拒绝的CU可以不发送任何消息而不是使用F1UE上下文修改来通知UE上下文修改过程失败。如果没接收任何响应，由于定时器正在驱动，那么DU在定时器到期之后可以认定F1 UE上下文修改需要过程已经失败(然而，相应的方案需要先决条件，即只有CU必须定期地从eNB接收X2 SGNB修改确认时，CU可以向DU发送F1 UE上下文修改确认消息)。
又例如，不具有F1 UE上下文修改拒绝消息而是通过在发送F1 UE上下文修改确认消息的同时包括拒绝指示IE来通知F1 UE上下文修改需要/确认过程失败的方法可以被使用。
图20是用于描述根据本公开的实施例的使用F1 UE上下文修改确认消息来通知UE上下文过程的失败的方法的流程图。
参照图20，在向CU发送UE上下文修改需要之后，DU驱动用于消息的发送的定时器。接收相应的消息之后，CU向eNB发送X2 SGNB修改需要，然后驱动定时器。如果RRC重配置过程由于给定原因(例如，UE侧过程失败)而失败，则eNB在定时器到期之后向CU发送X2 SGNB拒绝修改。
已经接收X2 SGNB拒绝修改的CU可以通过发送包括拒绝指示IE的F1UE上下文修改确认消息而不使用F1 UE上下文修改拒绝来通知UE上下文修改过程失败。下表说明了已被添加了相应拒绝指示IE的F1 UE上下文修改确认消息格式。
[表格4]
Figure BDA0003211518180000331
Figure BDA0003211518180000341
又例如，可以将在F1 UE上下文修改确认中不包括RRC容器IE的方法纳入考虑。
图21是用于描述根据本公开的实施例的通知UE上下文更新过程的失败、指示F1UE上下文确认修改消息中不包括RRC容器IE的方法的示图。
参照图21，不使用F1 UE上下文修改拒绝消息而是通过在发送F1 UE上下文修改确认消息的同时不有意地包括强制性RRC容器IE来通知F1 UE上下文修改需要/确认过程的失败的方法可以被使用。
下表说明了已经省略RRC容器IE的F1 UE上下文修改确认消息格式。
[表格5]
Figure BDA0003211518180000342
图22和23是用于描述根据本公开的各种实施例的用于在从第一节点到第二节点的UE上下文修改需要请求的确认之后的改变的方法的示图。如上所述，根据本发明实施例的第一节点可以被理解为NR基站的DU(gNB-DU)，第二节点可以被理解为NR基站的CU(gNB-CU)，第三节点可以被理解为LTE基站。
参照图22和23，如果确定UE上下文更新是必要的，则根据本公开的实施例的第一节点222a、232a可以向第二节点222b、232b发送请求UE上下文更新的消息(UE上下文修改需要)(S2201，S2301)。第二节点222b、232b可以向第一节点222a、232a发送用于确认消息的接收的消息(UE上下文修改确认)(S2202、S2302)。此外，响应于该请求，根据本公开的实施例的第二节点222b、232b可以向第三节点221、231发送用于UE上下文更新的消息(SGNB上下文修改需要)(S2203、S2303)。
如果如图22所示的在定时器到期之前还没有从第三节点221、231接收X2 SGNB修改确认或者如图23所示的已经从第三节点221、231接收作为对从第二节点222b、232b向第三节点221、231发送的X2 SGNB修改需要的响应的X2 SGNB拒绝修改消息(S2204)，那么根据本公开的实施例的第二节点222b、232b可以发送UE上下文修改请求消息，当它向第一节点222a、232a发送UE上下文修改请求消息时，UE上下文修改请求消息包括具有值“假”的完成指示符(S2204、S2304)。
此后，当具有值“假”的完成指示符被接收时，根据本公开的实施例的第一节点222a、232a可以向第二节点222b、232b重新发送UE上下文修改需要消息。
如上所述，包括完成指示符的确认消息可以被理解为如图所示的“有意义的确认”。
根据本公开的实施例，在UE上下文更新涉及多个节点的状况下，将UE上下文更新过程的结果信息通知给第一请求UE上下文更新的节点。因此，存在的效果是节点能够在没有非必要的资源消耗下执行适合于相应过程成功或失败的每个状况的操作。
虽然通过引用本公开的各种实施例示出和描述了本公开，但是本领域技术人员将理解，在不脱离由所附权利要求及其等同物所限定的本公开的精神和范围的情况下，可以在形式和细节上做出各种改变。

Claims (15)

1.一种无线通信系统中的第一节点的方法，该方法包括：
向第二节点发送请求用户设备(UE)上下文更新的第一消息；
响应于第一消息的发送，从第二节点接收指示UE上下文更新的完成的第二消息或指示UE上下文更新的失败的第三消息；并且
基于第二消息或第三消息的接收来确定是否向第二节点重发送第一消息，
其中，所述UE上下文更新的过程由请求在UE和第三节点之间执行的UE上下文更新的操作的消息从第二节点向第三节点的发送来启动。
2.根据权利要求1所述的方法，还包括：
当第三消息被接收时，基于第三消息向第二节点重发送第一消息，
其中，第三消息包括关于与第二节点、第三节点和UE之间的UE上下文更新失败的原因相关的至少一个实体的第一信息，以及关于第一消息的重发送数量的第二信息，以及用于第一消息的重发送的时间信息。
3.根据权利要求1所述的方法，
其中，第一节点和第二节点通过前传接口被连接，并且
其中，第二节点和第三节点通过X2接口被连接。
4.根据权利要求1所述的方法，还包括：
当第二消息被接收时，基于已更新UE上下文与UE通信，
其中，第二消息包括指示UE上下文更新的完成的指示信息和用于标识UE上下文的信息。
5.一种无线通信系统中的第二节点的方法，该方法包括：
从第一节点接收请求用户设备(UE)上下文更新的第一消息；
响应于第一消息的接收，向第三节点发送请求在第三节点和UE之间执行的UE上下文更新的操作的消息；
确认基于向第三节点发送的消息而被启动的UE上下文更新的结果；并且
基于确认的结果向第一节点发送指示UE上下文更新的完成的第二消息或指示UE上下文更新的失败的第三消息。
6.根据权利要求5所述的方法，还包括：
基于UE上下文更新的失败被确认，向第一节点发送第三消息，
其中，第三消息包括关于与第二节点、第三节点和UE之间的UE上下文更新失败的原因相关的至少一个实体的第一信息，以及关于第一消息的重发送数量的第二信息，以及用于第一消息的重发送的时间信息。
7.根据权利要求5所述的方法，
其中，第一节点和第二节点通过前传接口被连接，并且
其中，述第二节点和第三节点通过X2接口被连接。
8.根据权利要求5所述的方法，还包括：
基于UE上下文更新的完成被确认，向第一节点发送第二消息，
其中，第二消息包括指示UE上下文更新的完成的指示信息和用于标识UE上下文的信息。
9.一种无线通信系统中的第一节点，包括：
收发器；以及
至少一个处理器，被配置为：
控制收发器向第二节点发送请求用户设备(UE)上下文更新的第一消息，以及响应于第一消息的发送，从第二节点接收指示UE上下文更新的完成的第二消息或指示UE上下文更新的失败的第三消息，以及
基于第二消息或第三消息的接收确定是否向第二节点重发送第一消息，
其中，所述UE上下文更新的过程由请求在UE和第三节点之间执行的UE上下文更新的操作的消息从第二节点向第三节点的发送来启动。
10.根据权利要求9所述的第一节点，
其中，所述的至少一个处理器还进一步被配置为，当第三消息被接收时，基于第三消息控制收发器向第二节点重发送第一消息，并且
其中，第三消息包括关于与第二节点、第三节点和UE之间的UE上下文更新失败的原因相关的至少一个实体的第一信息，以及关于第一消息的重发送数量的第二信息，以及用于第一消息的重发送的时间信息。
11.根据权利要求9所述的第一节点，
其中，所述收发器包括被连接到第二节点的前传接口单元，以及
其中，第二节点和第三节点通过X2接口被连接。
12.根据权利要求9所述的第一节点，
其中，所述至少一个处理器还进一步被配置为，当第二消息被接收时，基于已更新UE上下文控制收发器执行与UE的通信，并且
其中，第二消息包括指示UE上下文更新的完成的指示信息和用于标识UE上下文的信息。
13.一种无线通信系统中的第二节点，包括：
收发器；以及
至少一个处理器，被配置为控制收发器：
从第一节点接收请求用户设备(UE)上下文更新的第一消息，
响应于第一消息的接收向第三节点发送请求在第三节点和UE之间执行的UE上下文更新的操作的消息，确认基于向第三节点发送的消息而被启动的UE上下文更新的结果，并且
基于确认的结果向第一节点发送指示UE上下文更新的完成的第二消息或者指示UE上下文更新的失败的第三消息。
14.根据权利要求13所述的第二节点，
其中，所述的至少一个处理器还进一步被配置为，基于UE上下文更新的失败被确认，控制收发器向第一节点发送第三消息，
其中，第三消息包括关于与第二节点、第三节点和UE之间的UE上下文更新失败的原因相关的至少一个实体的第一信息，以及关于第一消息的重发送数量的第二信息，以及用于第一消息的重发送的时间信息，并且
其中，所述的收发器包括被连接到第一节点的前传接口单元，以及被连接到第三节点的X2接口单元。
15.根据权利要求13所述的第二节点，
其中，所述至少一个处理器还进一步被配置为，基于UE上下文更新的完成被确认，控制收发器向第一节点发送第二消息，
其中，第二消息包括指示UE上下文更新的完成的指示信息和标识UE上下文的信息。
CN202080014585.6A 2019-02-14 2020-02-14 用于在无线通信系统中控制ue上下文的方法和装置 Pending CN113424587A (zh)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
KR10-2019-0017344 2019-02-14
KR20190017344 2019-02-14
KR10-2019-0018223 2019-02-15
KR1020190018223A KR20200099450A (ko) 2019-02-14 2019-02-15 무선 통신 시스템에서 단말 컨텍스트를 제어하는 방법 및 장치
PCT/KR2020/002112 WO2020167028A1 (en) 2019-02-14 2020-02-14 Method and apparatus for controlling ue context in wireless communication system

Publications (1)

Publication Number Publication Date
CN113424587A true CN113424587A (zh) 2021-09-21

Family

ID=72235300

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202080014585.6A Pending CN113424587A (zh) 2019-02-14 2020-02-14 用于在无线通信系统中控制ue上下文的方法和装置

Country Status (2)

Country Link
KR (1) KR20200099450A (zh)
CN (1) CN113424587A (zh)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107926069A (zh) * 2015-08-24 2018-04-17 三星电子株式会社 无线通信系统中用于通信的方法和装置
US20190037631A1 (en) * 2017-07-23 2019-01-31 Lg Electronics Inc. Method and apparatus for modifying radio bearer in cu-du split scenario

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107926069A (zh) * 2015-08-24 2018-04-17 三星电子株式会社 无线通信系统中用于通信的方法和装置
US20190037631A1 (en) * 2017-07-23 2019-01-31 Lg Electronics Inc. Method and apparatus for modifying radio bearer in cu-du split scenario

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
""38473_CR0070r3_(Rel-15)_R3-186121"", 3GPP TSG_RAN\\TSG_RAN, 6 December 2018 (2018-12-06) *
""38473_CR0195r1_(Rel-15)_R3-187213"", 3GPP TSG_RAN\\TSG_RAN, 6 December 2018 (2018-12-06) *
CATT: "TP for TS 38.473 on UE Context Management procedure", 《3GPP TSG-RAN WG3 NR ADHOC 1801 R3-180180》, 26 January 2018 (2018-01-26), pages 1 - 19 *
SAMSUNG: "R3-190446 "UE context modification refuse"", 3GPP TSG_RAN\\WG3_IU, no. 3, 15 February 2019 (2019-02-15) *
ZTE: "Discussion on SCell management in CU-DU deployment", 《3GPP TSG RAN WG3#99 MEETING R3-180899》, 2 March 2018 (2018-03-02), pages 1 - 5 *

Also Published As

Publication number Publication date
KR20200099450A (ko) 2020-08-24

Similar Documents

Publication Publication Date Title
US11259217B2 (en) Method and apparatus for supporting session continuity for 5G cellular network
US20200336949A1 (en) Method and apparatus for managing session to change a user plane function in a wireless communication system
KR102577006B1 (ko) 4g 및 5g 네트워크 이동 시 네트워크 슬라이스 지원 방법 및 장치
KR102388500B1 (ko) 듀얼 rrc 시스템에서 이동성을 처리하는 방법 및 장치
US11700552B2 (en) Method and device for switching a serving cell and method and device supporting on-demand system information message
US20240090065A1 (en) Method for processing rlc failure, network device and computer storage medium
US11330479B2 (en) Method for supporting data forwarding during conditional handover and dual stack protocol handover in next-generation mobile communication system
EP4125285A1 (en) Method and apparatus for redundant transmission for ultra-reliable services in 5g wireless network system
US11252599B2 (en) Method for supporting device-to-device communication through broadcast and groupcast based on QoS flow in wireless communication system
CN112073998B (zh) 提高无线通信系统中的服务可靠性的方法和装置
EP3662716B1 (en) Apparatus and method for transmitting uplink signals in wireless communication system
CN115460571A (zh) 由无线通信系统中的第一终端或第二终端执行的方法
EP3866559A1 (en) Method and apparatus for enhancing network selection accuracy in wireless communication system
JP7334243B2 (ja) 無線通信システムにおいて、モバイルエッジコンピューティングの移転を支援する方法及びその装置
US11395284B2 (en) Method and apparatus of indicating alternative resource at collision of configured grants
US20230354110A1 (en) Method and device for switching a serving cell and method and device supporting on-demand system information message
US20160309447A1 (en) Method and apparatus for paging between devices performing direct communication
US20240089726A1 (en) Method and apparatus for controlling ue context in wireless communication system
CN113678498A (zh) 用于在无线通信系统中传输数据的方法和设备
CN113412636B (zh) 支持对dn授权的pdu会话进行重新认证并根据dn授权数据的改变管理pdu会话的方法和装置
EP3913963B1 (en) Method and device for transmitting data in wireless communication system
CN113424587A (zh) 用于在无线通信系统中控制ue上下文的方法和装置
JP2021533612A (ja) １つのプロトコルデータユニットのセッションにおける２つのトンネルのセットアップの識別
US12010738B2 (en) Method and apparatus for enhancing reliability in wireless communication systems
US20220046729A1 (en) Method and apparatus for enhancing reliability in wireless communication systems

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