CN117580194A - 由用户设备执行的处理寻呼消息的方法及用户设备 - Google Patents

由用户设备执行的处理寻呼消息的方法及用户设备 Download PDF

Info

Publication number
CN117580194A
CN117580194A CN202210946584.6A CN202210946584A CN117580194A CN 117580194 A CN117580194 A CN 117580194A CN 202210946584 A CN202210946584 A CN 202210946584A CN 117580194 A CN117580194 A CN 117580194A
Authority
CN
China
Prior art keywords
rrc
user equipment
mbs
inactive state
tmgi
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
CN202210946584.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.)
Sharp Corp
Original Assignee
Sharp Corp
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 Sharp Corp filed Critical Sharp Corp
Priority to CN202210946584.6A priority Critical patent/CN117580194A/zh
Priority to PCT/CN2023/111440 priority patent/WO2024032544A1/zh
Publication of CN117580194A publication Critical patent/CN117580194A/zh
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W52/00Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02Power saving arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W52/00Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02Power saving arrangements
    • H04W52/0209Power saving arrangements in terminal devices
    • H04W52/0225Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal
    • H04W52/0248Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal dependent on the time of the day, e.g. according to expected transmission activity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W68/00User notification, e.g. alerting and paging, for incoming communication, change of service or the like
    • H04W68/02Arrangements for increasing efficiency of notification or paging channel
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/20Manipulation of established connections
    • H04W76/25Maintenance of established connections
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/20Manipulation of established connections
    • H04W76/27Transitions between radio resource control [RRC] states

Landscapes

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

Abstract

本发明提供由用户设备在不处于RRC连接态的情况下执行的处理寻呼消息的方法,所述用户设备能够在RRC非激活态下接收MBS多播会话,包括:监听寻呼消息,所述寻呼消息包括至少一个标识MBS多播会话的临时移动组标识TMGI;以及如果用户设备处于RRC非激活态,则在监听到的寻呼消息中的各个TMGI所指示的MBS多播会话当中的用户设备已加入的MBS多播会话中不存在未被配置为在RRC非激活态下接收的MBS多播会话时,不执行恢复RRC连接的操作。

Description

由用户设备执行的处理寻呼消息的方法及用户设备
技术领域
本发明涉及无线通信技术领域,更具体地,本发明涉及由用户设备执行的处理寻呼消息的方法及用户设备。
背景技术
一项关于5G组播广播服务架构改进的研究项目SI(具体见SP-190625)已获得批准。此SI的目标之一(称为目标A)是在5GS中支持通用MBS服务,可以受益于此特性的用例包括(但不限于)公共安全、V2X应用、透明IPv4/IPv6组播传输、IPTV、无线软件传输、群组通信和物联网应用等。相应的,在第三代合作伙伴计划(3rd Generation PartnershipProject:3GPP)RAN#86次全会上,提出了NR多播和广播服务(NR MBS)的工作项目(参见非专利文献:RP-193248:New WID:NR Multicast and Broadcast Service)获得批准。该工作项目旨在RAN中提供对目标A的支持。该工作项目的目标已达成,相关方案的具体描述见相关的3GPP版本17技术文档,例如TS38.300-h10、TS38.331-h10、TS38.321-h10等。在3GPP RAN#94次全会上,一项名为增强的NR广播多播工作项目被批准(参见非专利文献:RP-213568:New WID:Enhancements of NR Multicast and Broadcast Services),旨在对版本17的MBS广播多播进一步增强。该工作项目的目标之一为支持RRC非激活态的用户设备接收多播业务。
本发明讨论RAN达成支持RRC非激活态的用户设备接收多播业务所涉及的相关问题。
发明内容
本发明的目的在于提供能够节省功耗的由用户设备执行的处理寻呼消息的方法及用户设备。
根据本发明的一个方面,提供由用户设备在不处于RRC连接态的情况下执行的处理寻呼消息的方法,所述用户设备能够在RRC非激活态下接收MBS多播会话,包括:监听寻呼消息,所述寻呼消息包括至少一个标识MBS多播会话的临时移动组标识TMGI;以及如果用户设备处于RRC非激活态,则在监听到的寻呼消息中的各个TMGI所指示的MBS多播会话当中的用户设备已加入的MBS多播会话中不存在未被配置为在RRC非激活态下接收的MBS多播会话时,不执行恢复RRC连接的操作。
发明效果
根据本发明,能够避免UE不必要地发起RRC连接恢复过程,从而避免不必要的信令开销。
附图说明
通过下文结合附图的详细描述,本发明的上述和其它特征将会变得更加明显,其中:
图1的(a)~(c)是表示本发明涉及的接收MBS业务的无线承载的具体配置的示意图。
图2是表示基于本发明的实施例的处理寻呼消息的方法的流程图。
图3是表示基于本发明的实施例的处理寻呼消息的方法中的监听过程的一个示例的流程图。
图4是表示基于本发明的实施例的配置在RRC非激活态下接收的MBS多播会话的方法的流程图。
图5是本发明的实施例所提供的用户设备的简要框图。
具体实施方式
下面结合附图和具体实施方式对本发明进行详细阐述。应当注意,本发明不应局限于下文所述的具体实施方式。另外,为了简便起见,省略了对与本发明没有直接关联的公知技术的详细描述,以防止对本发明的理解造成混淆。
下面描述本发明涉及的部分术语,术语的具体含义可参见3GPP最新相关文档,例如TS38.300、TS38.321、TS38.323、TS38.331等。此外,本发明实施例不限于广播/组播业务,也可以应用于其他应用场景。
UE:User Equipment,用户设备。
RRC:Radio Resource Control,无线资源控制。
RRC_CONNECTED:RRC连接态。
RRC_INACTIVE:RRC非激活态。
RRC_IDLE:RRC空闲态。
RAN:Radio Access Network,无线接入网。
NR:New RAT,新无线接入技术。
MBS:Multicast/Broadcast Services,多播/广播业务。
PDCP:Packet Data Convergence Protocol,分组数据汇聚协议。
RLC:Radio Link Control,无线链路控制。
SDU:Service Data Unit,服务数据单元。将本层从上层接收或递交上层的数据包称为SDU。
PDU:Protocol Data Unit,协议数据单元。将本层从下层接收或递交下层的数据包称为PDU。例如,PDCP数据PDU是PDCP SDU增加PDCP报头后得到的数据包。
RB:Radio Bearer,无线承载。
MRB:MBS无线承载,即一个配置用于MBS传输的无线承载(Aradio bearer that isconfigured for MBS delivery)。
TMGI:Temporary Mobile Group Identity,临时移动组标识,用于标识一个MBS会话。
RNTI:Radio Network Temporary Identifier,无线网络临时标识。
PTM:Point to Multipoint,点到多点,一种MBS业务的递送(deliver)方式。在PTM递送方式中,基站将一份MBS数据包送给一组UE(gNB delivers a single copy of MBSdata packets to a set of UEs)。例如,基站采用G-RNTI加扰的群组公共物理下行控制信道PDCCH调度相同的G-RNTI加扰的群组公共物理下行共享信道PDSCH。
PTP:Point to Point,点到点,一种MBS业务的递送方式。在PTP递送方式中,RAN节点将多个MBS数据包的副本分别单独递送给每个UE(gNB individually deliversseparate copies of MBS data packets to each UEs independently),即基站采用UE专用RNTI加扰的UE专用PDCCH调度采用相同的UE专用RNTI加扰的UE专用PDSCH。
G-RNTI:Group RNTI,群组RNTI,用于加扰PTM的一个或多个MBS组播业务的调度和传输(Used to scramble the scheduling and transmission of PTM for one or moreMBS multicast services)。
本发明中,网络、基站和RAN可互换使用,所述网络可以是长期演进LTE网络、NR网络、增强的长期演进eLTE网络,也可以是3GPP后续演进版本中定义的其他网络。
目前,NR MBS业务包含MBS广播(或MBS广播会话)和MBS多播(或MBS多播会话)。MBS广播面向低服务质量QoS的业务提供仅下行的MBS传输模式,使得处于RRC连接态、RRC空闲态和RRC非激活态的UE均可以接收所述MBS业务,UE通过广播控制信道MCCH接收MBS广播的MBS配置。MBS多播需要UE与基站建立RRC连接,然后基站通过专用RRC信令(也称为RRC消息)为UE配置,并且接收这些MBS业务(或MBS多播会话)的无线承载MRB也可由基站通过专用RRC信令(例如RRC重配置消息)为UE配置,仅处于RRC连接态并且配置了MRB的UE才可以接收对应的MBS业务。MBS会话包括MBS广播会话和MBS多播会话,如未特别说明,本公开实施例中所述MBS会话是MBS多播会话。
图1的(a)~(c)是表示接收MBS多播的无线承载的具体配置的示意图。所述无线承载可以是仅配置了PTM传输的MRB(如图1的(a)所示),或者同时配置了PTM和PTP的分离MRB(split MRB)(如图1的(b)所示)或者仅配置了PTP传输的MRB(如图1的(c)所示)。需要说明的是,图1的(a)-(c)仅示出了承载对应的PDCP实体和RLC实体以及两者间的关系。在下行方向上,经PDCP实体封装后的PDCP PDU递交给RLC实体。
现有的NR MBS中,当一个MBS多播会话被核心网激活或基站有MBS多播会话数据要发送时,支持MBS的网络通过群组通知机制来通知处于RRC空闲态或RRC非激活态的UE。在接收到所述群组通知时,UE重新连接到网络以接收对应的MBS多播会话。所述群组通知使用物理下行控制信道PDCCH上的P-RNTI寻址(the group notification is addressed with P-RNTI on PDCCH),UE监测寻呼(Paging)信道。用于群组通知的寻呼消息中包含MBS会话标识TMGI,被用来寻呼所有已经加入了相关的MBS多播会话并处于RRC空闲态或RRC非激活态UE,换言之,不单独寻呼UE。
网络通过在UE的寻呼时刻(Paging occasion)传输寻呼消息来发起寻呼过程。一条寻呼消息可以寻址多个UE。所述寻呼消息中可以包含含有针对每个UE的pagingRecord字段(表示所寻呼的UE的标识)的pagingRecordList字段(表示所寻呼的UE的标识列表)和包含一个或多个TMGI的pagingGroupList字段(表示MBS多播会话的标识列表)以为特定MBS多播会话寻呼UE。其中,所述pagingRecord字段包含用户标识ue-Identity字段,并还可能包含用于指示寻呼消息是否由非3gPP访问的PDU会话产生的accessType字段。ue-Identity字段的取值可以是ng-5G-S-TMSI或fullI-RNTI,其中ng-5G-S-TMSI包含5G-S-TMSI(5G S-临时移动订阅标识符)是由5GC(5G核心网)提供的临时UE标识以在跟踪区域(tracking area)内唯一标识UE(终端)。fullI-RNTI是基站在用于挂起RRC连接的RRCRelease消息中为UE分配的标识。
UE在接收到来自网络的寻呼(paging)消息时,执行以下操作至少一项:
I.如果UE处于RRC非激活态,并且寻呼消息中包含的PagingRecord字段所包含的ue-Identity与UE存储的fullI-RNTI匹配(match),则发起RRC连接恢复过程(RRCconnection resumption procedure);如果寻呼消息中包含的PagingRecord字段所包含的ue-Identity与上层(例如NAS层)分配(或指示)的UE标识(即5G-S-TMSI)匹配,将ue-Identity和accessType(如果存在)转发(forward)给上层,并且UE执行进入RRC空闲态的操作。所述操作至少包括:重置媒体访问控制MAC实体、删除UE非激活访问层AS(AccessStratum)上下文(如果存在)、向上层指示释放RRC连接以及释放原因。
II.对于包含在寻呼消息的PagingGroupList字段中的每个TMGI,如果UE已经加入(join)该TMGI指示的MBS会话,将TMGI转发给上层。对于处于RRC空闲态的UE,上层在接收到所述TMGI后可以确定是否触发建立RRC连接;对处于RRC非激活态的UE,上层在接收到所述TMGI后可以准备接收对应的MBS会话。
III.如果UE处于RRC非激活态并且UE已经加入了包含在寻呼消息中的PagingGroupList字段的TMGI所指示的一个或多个MBS会话,并且所述寻呼消息中的PagingRecord字段包含的ue_Identity均不与上层分配的UE标识匹配,则发起RRC连接恢复过程。
需要说明的是,RRC连接恢复过程的目的是恢复一个被挂起的RRC连接,包括恢复SRB、DRB和多播MRB或执行基于RAN的通知区域RNA更新等。
3GPP已经达成要支持处于RRC非激活态的UE接收MBS多播会话,对于配置了可以在RRC非激活态接收的MBS多播会话的UE而言,在接收到寻呼消息中包含MBS多播会话对应的会话标识时,执行哪些操作以正确接收对应的MBS会话和/或避免不必要的信令开销或资源浪费是需要解决的问题。
以下参照图2和图3对本发明的实施方式的概要进行说明。图2和图3是用户设备在不处于RRC连接态的情况下执行的流程。
图2是表示基于本发明的实施例的处理寻呼消息的方法的流程图。
如图2所示,在201,用户设备监听寻呼消息,寻呼消息包括至少一个标识MBS多播会话的临时移动组标识TMGI。
在203和203’,确定寻呼消息中的各个TMGI对应的MBS多播会话当中的用户设备已加入的MBS多播会话是否存在不能在RRC非激活态下接收的MBS多播会话。
如果寻呼消息中的各个TMGI对应的MBS多播会话当中的用户设备已加入的MBS多播会话存在不能在RRC非激活态下接收的MBS多播会话,则在205,确定用户设备是否处于RRC非激活态。
如果用户设备处于RRC非激活态,则在207,基于用户设备保存的RRC连接上下文信息,恢复RRC连接,以接收对应的MBS多播会话。如果用户设备不处于RRC非激活态,则表明用户设备处于RRC空闲态,此时可以在207,建立RRC连接,以接收MBS多播会话。
另一方面,如果寻呼消息中的各个TMGI对应的MBS多播会话当中的用户设备已加入的MBS多播会话不存在不能在RRC非激活态下接收的MBS多播会话,则在211,确定用户设备是否处于RRC非激活态。
如果用户处于RRC非激活态,则在213,不恢复RRC连接而在RRC非激活态下接收MBS多播会话。此时,用户设备的RRC层可以指示RRC层的下层接收对应的MBS多播会话。
如果用户不处于RRC非激活态,则表明用户设备处于RRC空闲态,此时可以在207,建立RRC连接,以接收MBS多播会话。
由此,在用户设备处于RRC非激活态并且在监听到的寻呼消息中的各个TMGI所指示的MBS多播会话当中的用户设备已加入的MBS多播会话中不存在未被配置为在RRC非激活态下接收的MBS多播会话时,不执行恢复RRC连接的操作,从而能够避免恢复或建立RRC连接。
此外,对于监听到的寻呼消息中的各个TMGI,在该TMGI所指示的MBS多播会话未被配置为在RRC非激活态下接收的情况下,可以由用户设备的RRC层将该TMGI转发给RRC层的上层,从而使上层做好处理MBS会话的准备。
作为另一示例,如果用户设备处于RRC空闲态,则对于监听到的寻呼消息中的各个TMGI,均可以由用户设备的RRC层将该TMGI转发给RRC层的上层,上层可由此触发RRC层建立RRC连接。
此外,即使所监听到的寻呼消息并未包含该用户设备的由上层分配的用户标识或存储在UE的特定标识,如果寻呼消息中包括该用户设备已加入的MBS多播会话的TMGI,则该用户设备也可以恢复RRC连接以接收相应的MBS多播会话。
具体地,作为一个示例,如果用户设备处于RRC非激活态,则对于监听到的寻呼消息中的各个TMGI,在满足以下的第一条件的情况下,基于用户设备保存的RRC连接上下文信息恢复RRC连接:各个TMGI所指示的MBS多播会话中存在用户设备已加入的MBS多播会话,并且该MBS多播会话未被配置为在RRC非激活态下接收;寻呼消息中的用户设备标识均不与用户设备的RRC层的上层所指定的用户设备标识匹配。
此外,第一条件还可以包括:寻呼消息中的用户设备标识均不与存储在UE的特定标识匹配,特定标识被携带在由基站指示用户设备释放RRC连接时发送给用户设备的RRC释放消息中而发送给用户设备。
如果寻呼消息中存在与用户设备的RRC层的上层所指定的用户设备标识匹配的用户标识,则表明此寻呼过程由核心网络发起,如果寻呼消息中存在与用户设备所保存的特定标识匹配的用户标识,则表明此寻呼过程由基站发起。另一方面,在寻呼消息中的用户设备标识均不与存储在UE的特定标识匹配并且均不与该用户设备的上层指示的用户标识匹配的情况下,表明该寻呼消息并未因非MBS业务寻呼该用户设备。
作为另一示例,如果用户设备处于RRC非激活态,则对于监听到的寻呼消息中的各个TMGI,在该TMGI所指示的MBS多播会话是用户设备已加入的MBS多播会话,并且该MBS多播会话未被配置为在RRC非激活态下接收的情况下,由RRC层将该TMGI转发给RRC层的上层。
图3是表示基于本发明的实施例的处理寻呼消息的方法中的监听过程的一个示例的流程图。图3的流程是在执行对寻呼消息的监听操作之前执行的。在图3所示的示例中,寻呼消息中的各个TMGI所指示的MBS多播会话均被配置为能够在RRC非激活态下接收。
如图3所示,在301,用户设备从基站接收寻呼提前指示PEI,PEI包括被寻呼的用户设备的寻呼子组信息。
然后,在303,确定PEI是否包括指示该用户设备所在的寻呼子组的信息。
在PEI中的寻呼子组信息不包括指示用户设备所在的寻呼子组的信息的情况下,在305,不监听寻呼消息和所述PEI所指示的寻呼时刻。
在PEI中的寻呼子组信息包括指示用户设备所在的寻呼子组的信息的情况下,监听寻呼消息和PEI所指示的寻呼时刻。
通过图3所示的示例,能够进一步节省功耗。
以上参照图2和图3的说明仅仅是本发明的示例,各流程的顺序可以在本发明的范围内进行变更。例如,图2中判断用户设备是否处于RRC非激活态的操作也可以是步骤确定寻呼消息中的各个TMGI对应的MBS多播会话当中的用户设备已加入的MBS多播会话是否存在不能在RRC非激活态下接收的MBS多播会话之前执行。
以下提供实施例解决上述问题。
对接收到的寻呼消息中包含的TMGI,如果UE已加入该TMGI指示的MBS会话但该TMGI指示的MBS会话不是UE在RRC非激活态下接收的MBS会话,则执行RRC连接恢复过程;可选的,如果UE已加入该TMGI指示的MBS会话且该TMGI指示的MBS会话是UE在RRC非激活态下接收的MBS会话,则向下层发送指示信息,以触发下层接收对应的MBS会话。
换言之,对接收到的寻呼消息中包含的TMGI,如果UE已加入该TMGI指示的MBS会话且该TMGI指示的MBS会话是UE在RRC非激活态下接收的MBS会话,则不执行RRC连接恢复过程。
以下具体描述:
UE在接收到来自网络的寻呼(paging)消息时,执行以下操作至少一项:
A.如果UE处于RRC非激活态,并且寻呼消息中包含的PagingRecord字段所包含的ue-Identity与UE存储的fullI-RNTI匹配,则发起RRC连接恢复过程;如果寻呼消息中包含的PagingRecord字段所包含的ue-Identity与上层(例如NAS层)分配(或指示)的UE标识(即5G-S-TMSI)匹配,将ue-Identity和accessType(如果存在)转发给上层,并且UE执行进入RRC空闲态的操作。所述操作至少包括:重置媒体访问控制MAC实体、删除UE非激活访问层AS上下文(如果存在)、向上层指示释放RRC连接以及释放原因。
B.对于包含在寻呼消息中的每个TMGI,如果UE已经加入该TMGI指示的MBS会话并且所述TMGI指示的MBS会话不是UE在RRC非激活态下接收的MBS会话,则将TMGI转发给上层(例如NAS层)。备选的,对于包含在寻呼消息中的每个TMGI,如果UE处于RRC空闲态(或UE不处于RRC非激活态),则将TMGI转发给上层(例如NAS层)。
C.如果UE处于RRC非激活态并且UE已经加入了包含在寻呼消息中的PagingGroupList字段(或PagingRecord字段)的TMGI所指示的一个或多个MBS会话,并且所述TMGI指示的MBS会话不是UE在RRC非激活态下接收的MBS会话,并且所述寻呼消息中的PagingRecord字段包含的ue_Identity均不与上层分配的UE标识匹配,并且如果所述寻呼消息中的PagingRecord字段包含的ue_Identity均不与UE存储的fullI-RNTI匹配(这个条件是可选的),则发起RRC连接恢复过程。fullI-RNTI是基站为UE分配的标识,若UE保存有该标识,则表示UE曾与基站建立过连接,UE保存有与基站之间的RRC连接的上下文信息。因此,可以基于上下文信息恢复RRC连接。
D.如果UE处于RRC非激活态并且UE已经加入了包含在寻呼消息中的PagingGroupList字段的TMGI所指示的一个或多个MBS会话,并且所述TMGI指示的MBS会话是UE在RRC非激活态下接收的MBS会话,则执行以下操作至少一项:(1)将所述TMGI(或对应的G-RNTI或G-CS-RNTI)指示给下层(例如媒体接入控制MAC层);(2)向下层指示对应的MBS会话开始;(3)指示或触发下层接收对应的MBS会话。
通过上述实施例,当UE接收到的寻呼消息中的包含PagingGroupList字段中的所有TMGI对应的MBS会话中UE已经加入了的MBS会话都是UE在RRC非激活态下接收的MBS会话,则UE不发起RRC连接恢复过程,从而避免不必要的信令开销。
此外,为节能的目的,对于在RRC非激活状态下UE可以接收的MBS会话,基站在停止所述MBS会话数据传输时,可以向UE发送指示信息以指示UE所述MBS会话停止或指示UE停止接收所述MBS会话,以减少UE能耗。所述指示信息可以携带在下行控制信息DCI中或携带在媒体接入控制控制元素MAC CE中。在所述DCI或在所述MAC CE中可以包含MBS会话对应的TMGI或G-RNTI或MRB标识。也可以通过在DCI中设置对应位的值来指示加扰该DCI对应的PDCCH的G-RNTI对应的MBS会话停止。可选的,UE在接收到所述指示信息后挂起对应的MRB或者MAC层或物理层在接收到所述指示信息后,指示上层(例如RRC层),上层(例如RRC层)在接收到来自下层(例如MAC层或物理层)的指示后,挂起对应的MRB。
对处于RRC空闲态和RRC非激活态的UE,为了减少UE能耗,对寻呼的监听和接收定义了非连续接收机制DRX和扩展的不连续接收eDRX。UE在每个DRX周期(cycle)监听一个寻呼时刻(PO)。一个PO是一系列PDCCH监听时刻的集合,可以包含多个时隙(time slot),寻呼DCI可以在PO中由网络发送给UE。eDRX可以用于RRC_IDLE和RRC_INACTIVE。eDRX周期可以比DRX周期更长,从而比DRX更节省能耗。
为了进一步减少UE能耗,处于RRC_IDLE和RRC_INACTIVE的UE可以在寻呼时刻之前接收一个寻呼提前指示PEI,从而确定是否需要监听寻呼时刻,如果不需要则可以不监听寻呼时刻以及不接收寻呼消息。比如,当网络中有寻呼信息需要终端接收时,网络发送PEI指示信息,指示信息用于指示终端需要检测该指示信息对应的PO。终端在PO之前唤醒,进行时频同步,以及在确定的PO上进行寻呼PDCCH的检测以及可能的PDSCH接收。如果终端接收的指示信息中指示终端不需要检测该指示信息对应的PO,终端则不需要在对应的PO上进行检测,以及也不需要在PO前唤醒和接收SSB进行时频同步以准备可能的PDSCH接收。这样,终端能够通过网络的指示,可以避免不需要的唤醒和同步等动作,从而节省了终端的功耗。PEI可以包含UE的寻呼子组(subgroup)信息。UE接收PEI后,可以知道自己所在的寻呼子组是否将被寻呼,如果不会被寻呼则可以不必监听PEI所指示的PO,从而避免了接收不必要的寻呼DCI和寻呼消息。如果UE所在的寻呼子组在PEI中指示被寻呼了,则UE需要监听PEI所指示的PO。一个PEI可以关联多个PO,一个PEI也可以关联多个PF。
对处于RRC非激活态的UE,如果UE已经加入的MBS会话都是在RRC非激活态接收的MBS会话或都是配置为可在RRC非激活态接收的MBS会话,则可以按照PEI方式监听寻呼,即UE先接收PEI,并根据PEI的指示信息确定是否要监听寻呼时刻。
如果存在一个或多个UE已经加入的MBS会话是不能在RRC非激活态接收的MBS会话或不是配置为可在RRC非激活态接收的MBS会话,则忽略PEI而监听该UE对应的每个PO。
UE能力上报
UE在接收到来自基站的用于请求UE无线接入能力的UE能力请求消息UECapabilityEnquiry。
UE向基站发送用于指示UE能力信息的UECapabolityInformation消息。具体的,如果所述UECapabilityEnquiry消息中包含用于询问UE是否支持在RRC非激活态下接收MBS多播会话的字段ptmInInactiveRequest,如果UE支持在RRC非激活态下接收MBS多播会话,则在UECapabolitylnformation消息中包含用于指示UE支持在RRC非激活态下接收MBS多播会话的UEptmInInactive字段,并将其值设置为对应的值,例如,为“true”。
在RRC非激活态下接收的MBS会话的配置
上述实施例中所述UE在RRC非激活态下接收的MBS会话可以由基站通过RRC消息为UE配置。以下实施例描述基站如何为UE配置在RRC非激活态下接收的MBS会话的。
RRC重配置消息是用于修改一个RRC连接的指令(command),RRC释放消息被用于命令释放一个RRC连接或挂起(suspension of)一个RRC连接。如果RRC释放消息中包含指示RRC非激活态的配置的字段suspendConfig,则UE按照所述字段中的配置挂起RRC连接,否则UE释放RRC连接。以下实施例讨论的是如何为处于RRC非激活态UE配置PTM,故以下实施例均考虑RRC释放消息中包含suspendConfig字段的情形。此外,如未特别说明用于指示在UE进入RRC非激活态后需要继续接收的MBS会话的指示标识均可包含在suspendConfig字段中。
针对上述问题,本公开提供以下实施例。
在步骤401中,用户设备UE接收来自基站的RRC消息,其中包含一个指示标识用于指示在UE进入RRC非激活态后接收的MBS会话。
在步骤403中,基于接收到的所述RRC消息,用户设备UE执行与接收指示标识指示的MBS会话相关的操作,例如,执行操作A-C中的至少一项:
A.如果所述RRC消息中包含所述指示标识,则执行MAC部分重置;如果所述RRC消息中不包含所述指示标识,则执行MAC重置和/或释放缺省的MAC小区组配置(存在缺省的MAC小区组配置时才执行此操作)。
B.挂起(suspend)除SRB0和根据所述指示标识确定的在RRC非激活态下接收的多播MRB外的所有SRB和DRB和多播MRB。
C.向下层(例如PDCP层)指示除根据所述指示标识确定的在非激活态下接收的多播MRB外的所有DRB和多播MRB的PDCP挂起。在接收到来自上层(例如RRC层)的请求PDCP挂起时,发送PDCP实体(transmitting PDCP entity)可设置用于指示下一个将要传输的PDCPSDU的COUNT值的状态变量TX_NEXT为初始值和/或删除(discard)所有存储的PDCP PDU。在接收到来自上层(例如RRC层)的请求PDCP挂起时,接收PDCP实体(receiving PDCP entity)可确定由上层配置的用于控制等待未到达的PDCP SDU的时长定时器t-Reordering是否正在运行,如果所述定时器正在运行,停止并重置所述定时器和/或将所有存储的PDCP SDU执行头解压缩(header decompression)后按照COUNT值从小到大的顺序依次递交(deliver)上层,接收PDCP实体还可以设置用于指示下一个期望接收到的PDCP SDU的COUNT值的状态变量RX_NEXT和用于指示第一个尚未递交上层(例如服务数据适配协议SDAP实体)的PDCPSDU的COUNT值的状态变量RX_DELIV的值为初始值。其中COUNT是由超帧号HFN和PDCP序列号SN组成。
可选的,UE(或RRC层)向上层(例如,NAS层)指示指示标识指示的MBS会话对应的TMGI或指示标识指示的MRB对应的TMGI或指示标识指示的TMGI。
可选的,UE(或RRC层)向下层(例如,媒体接入控制MAC层)指示处于RRC非激活态时接收的MBS会话或MRB对应的G-RNTI或G-CS-RNTI或MRB标识或TMGI。MAC层在接收到所述指示或被配置了非激活态下接收的MBS会话或MRB时,可以监听配置为非激活态下接收的MBS会话对应的G-RNTI。
可选的,对于被配置在RRC非激活态下接收的MBS会话或MRB,如果对应的MBS会话或G-RNTI或G-CS-RNTI或TMGI被配置为需要HARQ反馈,UE在接收到指示进入RRC非激活态的RRC释放消息时(或RRC层)认为或向下层(例如MAC层)指示HARQ反馈未被使能或不需要HARQ反馈或HARQ反馈被去使能。MAC层在接收到所述指示或当UE处于非激活态时,针对被配置为非激活态下接收的MBS会话(或MRB)不执行HARQ反馈(或不指示物理层产生对接收到的TB的确认(acknowledgement)),换言之,对于配置了需要HARQ反馈的MBS会话,只有在UE处于RRC连接态(或UE不处于RRC非激活态)才执行HARQ反馈。
本公开所述MAC重置(或UE未被配置RRC非激活态下可接收的MBS会话时MAC实体执行的MAC重置操作)可包括以下操作中的至少一项:
1.停止除MBS广播非持续接收DRX定时器外的所有定时器。
2.设置所有上行HARQ进程的新数据指示NDI的值为0。
3.停止正在进行的随机接入过程。
4.清空除用于MBS广播和下行HARQ进程外的所有下行进程的软缓存(softbuffer)。
5.对于每个下行HARQ进程,认为下一个接收到的传输块是第一次传输。
本公开所述MAC部分重置(或UE被配置了RRC非激活态下可接收的MBS会话时MAC实体执行的MAC重置或MAC部分重置操作)可包括以下操作中的至少一项:
1.停止除MBS广播非持续接收DRX定时器和被配置为RRC非激活态下可接收的MBS会话对应的DRX定时器外的所有定时器。
2.清空除用于MBS广播的下行HARQ进程和用于RRC非激活态下可接收的MBS会话的下行HARQ进程外的所有下行进程的软缓存。
3.设置所有上行HARQ进程的新数据指示NDI的值为0。备选的,设置除被配置为RRC非激活态下可接收的MBS会话对应的上行HARQ进程外的所有上行HARQ进程的新数据指示NDI的值为0。
4.对于除被配置为RRC非激活态下可接收的MBS会话对应的下行HARQ进程外的每个下行HARQ进程,认为下一个接收到的传输块是第一次传输。
5.清空所有上行HARQ缓存。
6.停止正在进行的随机接入过程。
7.清空消息3的缓存。
需要说明的是,如果UE执行A-C中的多项,则交换执行顺序得到的实施例也是本公开保护的范围。执行步骤401和步骤403的实体可以是UE的RRC实体。
根据上述方法,能够支持RRC非激活态的用户设备接收多播业务,从而能够节省通信资源,提高通信效率。
MBS多播支持两种混合自动重传请求HARQ反馈模式,其中一种HARQ反馈模式是ACK-NACK反馈,即当UE正确接收到传输块时在物理上行控制信道PUCCH上传输HARQ-ACK信息且当UE未正确接收传输块时在PUCCH上传输HARQ-NACK信息;另一种HARQ反馈模式是仅NACK反馈(nack-only),即仅当UE未正确接收传输块时在PUCCH上传输HARQ-NACK信息。基站通过RRC重配置消息为每个MBS会话或G-RNTI或G-CS-RNTI配置是否需要HARQ反馈,这可通过为每个G-RNTI关联的字段harq-FeedbackEnablerMulticast配置。所述字段harq-FeedbackEnablerMulticast用于指示UE是否应该为MBS多播(或接收到由该G-RNTI加扰的传输块)提供HARQ反馈。进一步的,还可以为UE配置反馈模式为仅NACK反馈或ACK-NACK反馈,这通过harq-FeedbackOptionMulticast字段配置。harq-FeedbackOptionMulticast字段指示动态调度物理下行共享信道PDSCH或半静态调度SPS PDSCH MBS多播的反馈模式。
可以限定所述指示标识指示的MRB或MBS会话或TMGI或G-RNTI或G-CS-RNTI为未配置HARQ反馈的MRB或MBS会话或TMGI或G-RNTI或G-CS-RNTI,即未配置字段harq-FeedbackEnablerMulticast的MRB或MBS会话或TMGI或G-RNTI或G-CS-RNTI。
还可以限定如果所述指示标识指示在非激活态下接收的MRB或MBS会话或TMGI或G-RNTI或G-CS-RNTI为配置了HARQ反馈的MRB或MBS会话或TMGI或G-RNTI或G-CS-RNTI,当UE进入RRC非激活态后,不执行对应的MRB或MBS的HARQ反馈或指示为不需要HARQ反馈。
以下通过不同实施例具体描述携带所述指示标识的RRC消息和所述指示标识的指示方式。
实施例1
基站向UE发送RRC重配置消息RRCReconfiguration为处于RRC连接态的UE配置用于传输MBS会话的MRB,并在向UE发送的RRC释放消息RRCRelease中携带一个指示标识用于指示在UE进入RRC非激活态后收的MBS会话。
所述指示标识字段可以采用以下方式实现:
方式一:所述指示标识字段包含一个MRB标识列表(记为ptmReceptionInInactiveList字段),如果一个MBS会话对应的MRB标识包含在所述指示标识中,表示UE在进入RRC非激活态后需要接收该MBS会话或所述MRB标识对应的MRB。
具体的,UE在接收到的RRC释放消息包含suspendConfig时,如果RRC释放消息还包含所述指示标识,则执行以下操作中的至少一项:
A.执行MAC部分重置。
B.挂起(suspend)除SRB0和所述指示标识指示的多播MRB外的所有SRB和DRB和多播MRB。
C.向下层指示除所述指示标识指示的多播MRB外的所有DRB和多播MRB的PDCP挂起。
需要说明的是,如果UE执行A-C中的多项,则交换执行顺序得到的实施例也是本公开保护的范围。
如果RRC释放消息中不包含所述指示标识,则执行MAC重置和/或释放缺省的MAC小区组配置(存在缺省的MAC小区组配置时才执行此操作)。
换言之,当RRC释放消息包含所述指示标识时,不挂起所述指示标识指示的MRB(或挂起除SRB0和/或所述指示标识指示的MRB外的其他RB),即指示标识字段指示不挂起(suspend)的MRB。
【方式一的变形】
所述指示标识包含一个MRB标识列表,如果一个MBS会话对应的MRB标识未包含在所述指示标识中,表示UE在进入RRC非激活态后需要接收该MBS会话或所述MRB标识对应的MRB。换言之,UE在接收到进入RRC非激活态的指示时,挂起所述指示标识包含的MRB或挂起除SRB0和/或所述指示标识字段未指示的MRB外的其他RB),即指示标识指示要挂起的MRB。
方式二:所述指示标识包含一个TMGI列表,如果一个MBS会话对应的TMGI包含在所述指示标识中,表示UE在进入RRC非激活态后需要接收该MBS会话或该TMGI对应的MRB。
换言之,UE在接收到进入RRC非激活态的指示时,不挂起所述指示标识包含的TMGI对应的MRB(或挂起除SRB0和/或所述指示标识指示外的其他RB),即指示标识指示不挂起的MRB对应的TMGI。
具体的,UE在接收到的RRC释放消息包含suspendConfig时,如果RRC释放消息还包含所述指示标识,则执行以下操作中的至少一项:
A.执行MAC部分重置。
B.挂起(suspend)除SRB0和所述指示标识指示的TMGI对应的多播MRB外的所有SRB和DRB和多播MRB。
C.向下层指示除所述指示标识指示的TMGI对应的多播MRB外的所有DRB和多播MRB的PDCP挂起。
需要说明的是,如果UE执行A-C中的多项,则交换执行顺序得到的实施例也是本公开保护的范围。
如果RRC释放消息中不包含所述指示标识,则执行MAC重置和/或释放缺省的MAC小区组配置(存在缺省的MAC小区组配置时才执行此操作)。
【方式二的变形】
所述指示标识包含一个TMGI列表,如果一个MBS会话对应的TMGI未包含在所述指示标识中,表示UE在进入RRC非激活态后需要接收该MBS会话或该TMGI对应的MRB。换言之,UE在接收到进入RRC非激活态的指示时,挂起所述指示标识包含的TMGI对应的MRB或挂起除SRB0和/或所述指示标识未指示的TMGI对应的MRB外的其他RB),即指示标识指示要挂起的MRB对应的TMGI。
方式三:所述指示标识包含一个G-RNTI或G-CS-RNTI列表,如果一个MBS会话对应的G-RNTI或G-CS-RNTI包含在所述指示标识中,表示UE在进入RRC非激活态后需要接收该MBS会话或该G-RNTI或G-CS-RNTI对应的MRB。其中,G-CS-RNTI用于加扰一个或多个MBS多播服务的半静态调度SPS群组公共PDSCH和激活/去激活SPS群组公共PDSCH。
换言之,UE在接收到进入RRC非激活态的指示时,不挂起所述指示标识包含的G-RNTI或G-CS-RNTI对应的MRB(或挂起除SRB0和/或所述指示标识指示外的其他RB),即指示标识指示不挂起的MRB对应的G-RNTI或G-CS-RNTI。
具体的,UE在接收到的RRC释放消息包含suspendConfig时,如果RRC释放消息还包含所述指示标识,则执行以下操作中的至少一项:
A.执行MAC部分重置。
B.挂起(suspend)除SRB0和所述指示标识指示的G-RNTI或G-CS-RNTI对应的多播MRB外的所有SRB和DRB和多播MRB。
C.向下层指示除所述指示标识指示的G-RNTI或G-CS-RNTI对应的多播MRB外的所有DRB和多播MRB的PDCP挂起。
需要说明的是,如果UE执行A-C中的多项,则交换执行顺序得到的实施例也是本公开保护的范围。
如果RRC释放消息中不包含所述指示标识,则执行MAC重置和/或释放缺省的MAC小区组配置(存在缺省的MAC小区组配置时才执行此操作)。
【方式三的变形】
所述指示标识包含一个G-RNTI或G-CS-RNTI列表,如果一个MBS会话对应的G-RNTI或G-CS-RNTI未包含在所述指示标识中,表示UE在进入RRC非激活态后需要接收该MBS会话或该G-RNTI或G-CS-RNTI对应的MRB。换言之,UE在接收到进入RRC非激活态的指示时,挂起所述指示标识包含的G-RNTI或G-CS-RNTI对应的MRB或挂起除SRB0和/或所述指示标识未指示的G-RNTI或G-CS-RNTI对应的MRB外的其他RB),即指示标识指示要挂起的MRB对应的G-RNTI或G-CS-RNTI。
方式四:所述指示标识包含一个位图,位图中的每一位对应一个MRB(或者位图中的每一位对应一个未配置为需要HARQ反馈的MBS会话或MRB)。例如,按照MRB标识从小到大的顺序依次对应位图中的位。位图中对应位取值为1,表示UE在进入RRC非激活态后需要接收所述MRB标识对应的MBS会话或接收所述MRB标识对应的MRB。位图中对应位取值为0,表示UE在进入RRC非激活态后不接收所述MRB标识对应的MBS会话或不接收所述MRB标识对应的MRB。换言之,UE在接收到进入RRC非激活态的指示时,不挂起位图中对应位取值为1的MRB(或挂起除SRB0和/或位图中对应位取值为1的MRB外的其他RB),即位图中对应位取值为1指示不挂起的MRB,取值为0指示挂起的MRB。
具体的,UE在接收到的RRC释放消息包含suspendConfig时,如果RRC释放消息还包含所述位图,则执行以下操作中的至少一项:
A.执行MAC部分重置。
B.挂起(suspend)除SRB0和所述位图取值为1的位对应的多播MRB外的所有SRB和DRB和多播MRB。
C.向下层指示除所述位图取值为1的位对应的多播MRB外的所有DRB和多播MRB的PDCP挂起。
相比于方式一、方式二和方式三,位图方式能节省信令开销。
【方式四的变形】
所述指示标识包含一个位图,位图中的每一位对应一个MRB(或者位图中的每一位对应一个未配置为需要HARQ反馈的MBS会话或MRB)。例如,按照MRB标识从小到大的顺序依次对应位图中的位。位图中对应位取值为1,表示UE在进入RRC非激活态后不需要接收该MBS会话或所述MRB标识对应的MRB。换言之,UE在接收到进入RRC非激活态的指示时,挂起位图为1的位对应的MRB,即指示标识指示挂起的MRB。
方式五:所述指示标识用于指示UE在进入RRC非激活态后仍然接收未配置为需要HARQ反馈的MBS会话或MRB。换言之,当接收到的RRC消息中包含所述指示标识时,UE不挂起未配置为需要HARQ反馈的MBS会话对应的MRB或UE不挂起未配置为需要HARQ反馈的MRB。即当接收到的RRC消息中包含所述指示标识时,UE挂起配置了需要HARQ反馈的MBS会话对应的MRB或UE挂起配置了需要HARQ反馈的MRB。
具体的,在接收到的RRC释放消息包含suspendConfig时,如果所述RRC释放消息还包含用于指示UE在非激活态接收配置为不需要HARQ反馈的MRB或MBS会话的指示标识,则执行以下操作A-C中的至少一项:
A.执行MAC部分重置。
B.挂起(suspend)除SRB0和所述未配置为需要HARQ反馈的MBS多播对应的MRB外的所有SRB和DRB和多播MRB。
C.向下层指示除所述未配置为需要HARQ反馈的MBS多播对应的多播MRB外的所有DRB和多播MRB的PDCP挂起。
如果RRC释放消息中不包含所述指示标识,则执行MAC重置和/或释放缺省的MAC小区组配置(存在缺省的MAC小区组配置时才执行此操作)。
实施例2
基站采用RRC重配置消息为处于RRC连接态的UE配置用于传输MBS会话的MRB,并在对应的MRB的配置字段中包含一个指示标识,用来指示当UE进入RRC非激活态后是否接收该MRB。
UE在接收到的RRC释放消息包含suspendConfig时,如果至少一个MRB被配置了所述指示标识,则执行以下操作中的至少一项:
A.执行MAC部分重置。
B.挂起(suspend)除SRB0和配置了所述指示标识的多播MRB外的所有SRB和DRB和多播MRB。
C.向下层指示除配置了所述指示标识的多播MRB外的所有DRB和多播MRB的PDCP挂起。
需要说明的是,如果UE执行A-C中的多项,则交换执行顺序得到的实施例也是本公开保护的范围。
如果所有MRB都未被配置所述指示标识,则执行MAC重置和/或释放缺省的MAC小区组配置(存在缺省的MAC小区组配置时才执行此操作)。
【实施例2的变形】
基站通过RRC重配置消息包含一个指示标识,用于指示UE在RRC非激活态接收的MBS会话或MRB对应的G-RNTI或G-CS-RNTI或TMGI。相应地,实施例2中所述的在RRC非激活态接收的MRB就是该指示标识指示的MBS会话或MRB对应的G-RNTI或G-CS-RNTI或TMGI对应的MRB。
实施例3
基站采用RRCRelease消息为UE配置并指示为处于RRC连接态的UE传输MBS会话的MRB。
处于RRC非激活态的UE因要接收MBS多播(例如接收到寻呼消息,其中包含UE已经加入的一个或多个MBS会话对应的TMGI)向基站发送用于请求恢复一个挂起的RRC连接或用于执行基于RAN的通知区域(RNA)更新的RRC恢复请求消息RRCResumeRequest,所述消息中包含一个原因字段ResumeCause,其取值为UE想要接收的一个或多个MBS会话的TMGI或者用于指示UE要接收MBS会话而触发发送恢复RRC连接请求对应的值。
UE接收来自基站的包含suspendConfig字段的RRC释放消息,所述消息中包含指示UE在非激活态接收的MBS会话的MRB的配置信息。UE根据所述配置信息配置对应的MRB并接收对应的MBS会话。
对于同时配置了PTM和PTP传输的MRB,可以规定当UE处于RRC非激活态时,挂起PTP传输,即UE仅从PTM接收MBS会话。
图5是本发明涉及的用户设备UE的简要结构框图。如图5所示,该用户设备UE500包括处理器501和存储器502。处理器501例如可以包括微处理器、微控制器、嵌入式处理器等。存储器502例如可以包括易失性存储器(如随机存取存储器RAM)、硬盘驱动器(HDD)、非易失性存储器(如闪速存储器)、或其他存储器等。存储器502上存储有程序指令。该指令在由处理器501运行时,可以执行本发明详细描述的由用户设备执行的上述方法。
另外,运行在根据本发明的设备上的计算机可执行指令或者程序可以是通过控制中央处理单元(CPU)来使计算机实现本发明的实施例功能的程序。该程序或由该程序处理的信息可以临时存储在易失性存储器(如随机存取存储器RAM)、硬盘驱动器(HDD)、非易失性存储器(如闪速存储器)、或其他存储器***中。
用于实现本发明各实施例功能的计算机可执行指令或程序可以记录在计算机可读存储介质上。可以通过使计算机***读取记录在所述记录介质上的程序并执行这些程序来实现相应的功能。此处的所谓“计算机***”可以是嵌入在该设备中的计算机***,可以包括操作***或硬件(如***设备)。“计算机可读存储介质”可以是半导体记录介质、光学记录介质、磁性记录介质、短时动态存储程序的记录介质、或计算机可读的任何其他记录介质。
用在上述实施例中的设备的各种特征或功能模块可以通过电路(例如,单片或多片集成电路)来实现或执行。设计用于执行本说明书所描述的功能的电路可以包括通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、或其他可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或上述器件的任意组合。通用处理器可以是微处理器,也可以是任何现有的处理器、控制器、微控制器、或状态机。上述电路可以是数字电路,也可以是模拟电路。因半导体技术的进步而出现了替代现有集成电路的新的集成电路技术的情况下,本发明的一个或多个实施例也可以使用这些新的集成电路技术来实现。
此外,本发明并不局限于上述实施例。尽管已经描述了所述实施例的各种示例,但本发明并不局限于此。安装在室内或室外的固定或非移动电子设备可以用作终端设备或通信设备,如AV设备、厨房设备、清洁设备、空调、办公设备、自动贩售机、以及其他家用电器等。
如上,已经参考附图对本发明的实施例进行了详细描述。但是,具体的结构并不局限于上述实施例,本发明也包括不偏离本发明主旨的任何设计改动。另外,可以在权利要求的范围内对本发明进行多种改动,通过适当地组合不同实施例所发明的技术手段所得到的实施例也包含在本发明的技术范围内。此外,上述实施例中所描述的具有相同效果的组件可以相互替代。

Claims (10)

1.一种由用户设备在不处于RRC连接态的情况下执行的处理寻呼消息的方法,所述用户设备能够在RRC非激活态下接收MBS多播会话,包括:
监听寻呼消息,所述寻呼消息包括至少一个标识MBS多播会话的临时移动组标识TMGI;以及
如果用户设备处于RRC非激活态,则在监听到的寻呼消息中的各个TMGI所指示的MBS多播会话当中的用户设备已加入的MBS多播会话中不存在未被配置为在RRC非激活态下接收的MBS多播会话时,不执行恢复RRC连接的操作。
2.根据权利要求1所述的方法,还包括:
对于监听到的寻呼消息中的各个TMGI,在该TMGI所指示的MBS多播会话未被配置为在RRC非激活态下接收的情况下,由所述用户设备的RRC层将该TMGI转发给所述RRC层的上层。
3.根据权利要求1所述的方法,还包括:
如果所述用户设备处于RRC空闲态,则对于监听到的寻呼消息中的各个TMGI,由所述用户设备的RRC层将该TMGI转发给所述RRC层的上层,以建立RRC连接。
4.根据权利要求1所述的方法,还包括:
如果所述用户设备处于RRC非激活态,则对于监听到的寻呼消息中的各个TMGI,在满足以下的第一条件的情况下,基于所述用户设备保存的RRC连接上下文信息恢复RRC连接:
所述各个TMGI所指示的MBS多播会话中存在所述用户设备已加入的MBS多播会话,并且该MBS多播会话未被配置为在RRC非激活态下接收;
所述寻呼消息中的用户设备标识均不与所述用户设备的RRC层的上层所指定的用户设备标识匹配。
5.根据权利要求4所述的方法,其中,所述第一条件还包括:
所述寻呼消息中的用户设备标识均不与存储在所述UE的特定标识匹配,所述特定标识被携带在由基站指示所述用户设备释放RRC连接时发送给所述用户设备的RRC释放消息中而发送给所述用户设备。
6.根据权利要求4所述的方法,还包括:
如果所述用户设备处于RRC非激活态,则对于监听到的寻呼消息中的各个TMGI,在满足以下第二条件的情况下,由所述RRC层将该TMGI转发给所述RRC层的上层:
该TMGI所指示的MBS多播会话是所述用户设备已加入的MBS多播会话,并且该MBS多播会话未被配置为在RRC非激活态下接收。
7.根据权利要求1所述的方法,还包括:
如果所述用户设备处于非激活态,则对于监听到的寻呼消息中的各个TMGI,在该TMGI所指示的MBS多播会话是所述用户设备已加入的会话,并且该MBS多播会话被配置为在RRC非激活态下接收,则所述用户设备的RRC层指示所述RRC层的下层接收对应的MBS多播会话。
8.根据权利要求1所述的方法,还包括:
监听来自基站的指示MBS会话停止的指示消息;以及
响应于接收到所述指示消息,停止接收MBS多播会话。
9.根据权利要求1所述的方法,其中,所述用户设备已加入的各个TMGI所指示的MBS多播会话均被配置为能够在RRC非激活态下接收,
在所述监听寻呼消息之前,所述方法还包括:
从基站接收寻呼提前指示PEI,所述PEI包括被寻呼的用户设备的寻呼子组信息;
在所述寻呼子组信息不包括指示所述用户设备所在的寻呼子组的信息的情况下,不监听所述寻呼消息和所述PEI所指示的寻呼时刻;以及
在所述寻呼子组信息包括指示所述用户设备所在的寻呼子组的信息的情况下,监听所述寻呼消息和所述PEI所指示的寻呼时刻。
10.一种用户设备,包括:
处理器;以及
存储器,存储有指令,
其中,所述指令在由所述处理器运行时执行根据权利要求1至9中任一项所述的方法。
CN202210946584.6A 2022-08-08 2022-08-08 由用户设备执行的处理寻呼消息的方法及用户设备 Pending CN117580194A (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202210946584.6A CN117580194A (zh) 2022-08-08 2022-08-08 由用户设备执行的处理寻呼消息的方法及用户设备
PCT/CN2023/111440 WO2024032544A1 (zh) 2022-08-08 2023-08-07 由用户设备执行的处理寻呼消息的方法及用户设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210946584.6A CN117580194A (zh) 2022-08-08 2022-08-08 由用户设备执行的处理寻呼消息的方法及用户设备

Publications (1)

Publication Number Publication Date
CN117580194A true CN117580194A (zh) 2024-02-20

Family

ID=89850787

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210946584.6A Pending CN117580194A (zh) 2022-08-08 2022-08-08 由用户设备执行的处理寻呼消息的方法及用户设备

Country Status (2)

Country Link
CN (1) CN117580194A (zh)
WO (1) WO2024032544A1 (zh)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021120018A1 (zh) * 2019-12-17 2021-06-24 华为技术有限公司 一种通信方法及装置
WO2022017527A1 (zh) * 2020-07-23 2022-01-27 华为技术有限公司 一种数据传输方法、装置以及***
CN114071805B (zh) * 2020-08-03 2024-03-19 大唐移动通信设备有限公司 业务处理方法、信息指示方法、终端和网络设备
CN114375072A (zh) * 2020-10-14 2022-04-19 夏普株式会社 无线连接控制方法以及用户设备
EP4233418A4 (en) * 2020-10-22 2024-04-24 Samsung Electronics Co., Ltd. METHOD AND SYSTEM FOR MANAGING NOTIFICATION AND CONFIGURATION OF SERVICES FOR AN MBS SERVICE IN A 5G COMMUNICATION NETWORK

Also Published As

Publication number Publication date
WO2024032544A1 (zh) 2024-02-15

Similar Documents

Publication Publication Date Title
JP6506887B2 (ja) 無線端末及び基地局
WO2012126210A1 (zh) 确定挂起mbms业务重新恢复的方法及装置、用户设备
WO2018028631A1 (zh) 单小区多播业务的信息变更传输方法和设备
WO2018028562A1 (zh) 用户设备、基站和相关方法
JP2019013033A (ja) 無線端末及びネットワーク装置
WO2022078384A1 (zh) 用户设备执行的传输方法、用户设备、基站以及基站执行的传输方法
WO2022078328A1 (zh) 用户设备执行的传输方法、用户设备、基站以及基站执行的传输方法
WO2022083533A1 (zh) 非连续性接收方法以及用户设备
WO2022138450A1 (ja) 通信制御方法及びユーザ装置
CN117580194A (zh) 由用户设备执行的处理寻呼消息的方法及用户设备
WO2021155547A1 (zh) 数据接收方法、装置、设备及存储介质
CN116803155A (zh) 用于管理drx和wus操作以接收mbs服务的方法和***
WO2024032500A1 (zh) 由用户设备执行的方法以及用户设备
WO2023001240A1 (zh) 由用户设备ue执行的方法及用户设备
CN118433935A (zh) 用户设备、基站及其方法
WO2024067602A1 (zh) 由用户设备执行的方法以及用户设备
WO2024120476A1 (zh) 由用户设备执行的方法以及用户设备
WO2023036287A1 (zh) 用户设备执行的方法、基站的传输方法及用户设备
WO2023036173A1 (zh) 状态报告发送方法、无线承载重传执行方法及用户设备
WO2024120475A1 (zh) 恢复rrc连接的方法以及用户设备
WO2023065224A1 (en) Discontinuous reception for multicast and broadcast service
JP7481588B2 (ja) 通信方法、ユーザ装置、移動通信システム、チップセット、及びプログラム
JP7508576B2 (ja) 通信制御方法
JP7469564B2 (ja) 通信制御方法、ユーザ装置、プロセッサ、ネットワークノード及び移動通信システム
WO2022184045A1 (zh) 多播业务的接收方法、装置及电子设备

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication