背景技术
长期演进(LTE)***中定义了多个终端状态,如无线资源控制空闲态(RRC_IDLE)、无线资源控制连接态(RRC_CONNECTED)、轻连接(lightconnection)等。随着无线通信***的发展,终端类型和业务类型多样化,终端省电、节约网络资源和满足各种业务类型的需求并存。下面介绍各种状态下终端可执行的行为。
1、RRC_IDLE下可以执行的UE行为:
-PLMN选择;
-NAS配置DRX;
-***信息广播;
-寻呼;
-Cell重选方式的移动性;
-UE被分配一个在一定跟踪区域内唯一的标识;
-eNB不保存UE context(UE上下文信息);
-可以进行sidelink通信的发送接收(D2D通信);
-Sidelink发现的通知和监听(D2D发现)。
2、RRC_CONNECTED下可以执行的UE行为:
-UE有E-UTRAN-RRC的连接;
-E-UTRAN侧有UE的上下文信息;
-E-UTRAN知道UE所属的小区并分配小区内UE标识C-RNTI;
-Network和UE间可以利用C-RNTI收发数据;
-Network控制的移动性;
-邻小区测量;
-可以进行sidelink通信的发送接收(D2D通信);
-Sidelink发现的通知和监听(D2D发现);
-PDCP/RLC/MAC层:
-UE与网络间进行收发数据;
-UE监听关于共享数据信道的控制信令信道以便查看是否有分配给该UE的共享数据信道上的传输。
-UE上报信道质量信息和反馈信息给eNB;
-非连接接收(DRX)周期由而NB控制,根据UE节能以及资源利用率的活跃程度来配置。
LTE***中支持的状态跃迁,包括从RRC_IDLE到RRC_CONNECTED状态,终端需要进行接入或者重建过程;从RRC_CONNECTED状态,则可以通过释放过程进入到RRC_IDLE状态。
为了同时保证终端省电和快速数据传输,目前引入了一种终端状态:Inactive状态,该Inactive状态又被称为非激活态或不活跃连接态。这种状态下终端(UE)保持核心网连接,但不进行空口连接态的常规操作(如切换、上行定时更新、无线链路监控等),不分配直接用于空口传输的终端标识(如C-RNTI),因此不能直接进行空口调度传输。在Inactive状态下,终端需要监听寻呼消息,以接收来自网络侧的呼叫。Inactive状态则有着以下特点:
-核心网看该终端处于连接状态;
-移动性是终端执行的,在网络侧预配置的无线接入网(RAN)跟踪区域内,通过小区重选来执行,而不是切换过程进行;
-终端被分配了在网络侧预配置的RAN跟踪区域内的唯一用户标识。
Inactive状态下,网络侧为终端分配一定区域内有效的RAN标识,该标识用于在Inactive状态下识别终端,可以在网络侧查找终端或终端主动发起上行接入时用该标识作为身份识别进入连接态,该标识可以称为Inactive UE ID,也可以称为resume UE ID。该标识不同于全球唯一的IMSI或连接态终端标识C-RNTI,该标识长度介于两者之间(例如Inactive UE ID长度为40bit,C-RNTI长度为16bit),只在包含多个小区或多个基站(eNB)的一定区域内有效,如果超过该区域,终端需要更新Inactive UE ID。
当终端在Inactive状态时,与基站之间没有连接,但是可以接收寻呼,可以发起业务,进入该状态可以起到节省终端电量的作用。终端在Inactive状态时,根据Inactive状态的寻呼周期来监听寻呼,而终端在RRC_IDLE态时,根据RRC_IDLE态的寻呼周期来监听寻呼。终端在Inactive状态时的寻呼周期为基站配置的,而终端在RRC_IDLE态时的寻呼周期,是核心网配置的。二者之间的关系没有确定。
如果网络侧(包括基站和核心网)因为自身原因释放了Inactive终端的上下文,但是却没通知给终端,或者在空口对终端的通知消息丢失,则会导致终端和网络侧的状态理解不一致,网络侧理解终端为IDLE态(接入层AS和非接入NAS层都是IDLE),而终端的AS认为自己是Inactive态,终端的NAS认为自己是CONNECTED态。因为Inactive状态和IDLE态的寻呼周期不同,此时如果网络侧发起核心网寻呼,会导致终端无法收到该寻呼。
可以看出,在终端处于非激活态(Inactive)时,由于网络与终端对终端状态的理解可能不一致,因此可能导致Inactive状态下的终端的寻呼出现问题。
具体实施方式
为使本发明要解决的技术问题、技术方案和优点更加清楚,下面将结合附图及具体实施例进行详细描述。在下面的描述中,提供诸如具体的配置和组件的特定细节仅仅是为了帮助全面理解本发明的实施例。因此,本领域技术人员应该清楚,可以对这里描述的实施例进行各种改变和修改而不脱离本发明的范围和精神。另外,为了清楚和简洁,省略了对已知功能和构造的描述。
应理解,说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本发明的至少一个实施例中。因此,在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外,这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。
在本发明的各种实施例中,应理解,下述各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本发明实施例的实施过程构成任何限定。
另外,本文中术语“***”和“网络”在本文中常可互换使用。
应理解,本文中术语“和/或”,仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。另外,本文中字符“/”,一般表示前后关联对象是一种“或”的关系。
在本申请所提供的实施例中,应理解,“与A相应的B”表示B与A相关联,根据A可以确定B。但还应理解,根据A确定B并不意味着仅仅根据A确定B,还可以根据A和/或其它信息确定B。
本发明实施例中,终端可以是移动电话(或手机),或者其他能够发送或接收无线信号的设备,包括用户设备(UE)、个人数字助理(PDA)、无线调制解调器、无线通信装置、手持装置、膝上型计算机、无绳电话、无线本地回路(WLL)站、能够将移动信号转换为WiFi信号的CPE(Customer Premise Equipment,客户终端)或移动智能热点、智能家电、或其他不通过人的操作就能自发与移动通信网络通信的设备等。
本发明实施例中,所述基站的形式不限,可以是宏基站(Macro Base Station)、微基站(Pico Base Station)、Node B(3G移动基站的称呼)、增强型基站(eNB)、家庭增强型基站(Femto eNB或Home eNode B或Home eNB或HeNB)、中继站、接入点、RRU(Remote RadioUnit,远端射频模块)、RRH(Remote Radio Head,射频拉远头)等。另外,随着5G技术的发展,基站可能替换为其他功能节点,如中央单元(CU,Central Unit)和分布式单元(DU,Distributed Unit)。本发明实施例可以应用于上述场景,下面将简单介绍其中的LTE组网和5G的一种可能组网场景中的RAN侧架构。
LTE组网场景:基站+终端
图1是典型的LTE架构。基站(eNB)下有多个小区(cell),连接态的终端(UE)与小区进行空口数据收发,连接态的UE被分配小区内唯一的UE标识(C-RNTI)。基站之间可以通过X2接口通信,基站与核心网之间可以通过S1接口通信。
5G组网场景:网络侧节点分为中央单元(CU,Central Unit)和分布式单元(DU,Distributed Unit),用户侧节点为终端(UE)。
图2是未来移动通信5G可能采用的一种架构,网络侧节点包括中央单元和分布式单元,一个中央单元控制一定区域内部署的多个分布式单元,这些分布式单元也可以被称为传输点(TRP,Transmission Reception Point)。TRP与终端进行空口传输。一个或多个传输点可以同时为终端服务,进行数据传输,这里也需要通过网络侧为终端分配的终端空口唯一标识来进行数据调度和传输,这个标识可以是C-RNTI或TRP-RNTI。
本发明实施例可以应用于上述两种RAN架构,也可以应用于除上述场景外的其他场景。为统一描述,本文中将网络侧无线信令和数据收发节点都统称为基站,包括图1中的eNB以及图2中的CU/DU(具体收发点为TRP)。另外,本文中将用于终端连接态传输的终端唯一标识称为终端空口传输唯一标识,该标识在传统LTE中即为小区无线网络临时标识(C-RNTI C-Radio Network Temporary Identity)。Inactive态的终端在区域内唯一标识称为Inactive UE ID。
请参照图3,本发明实施例提供了一种寻呼方法,应用于终端侧,包括:
步骤31,处于非激活态的终端,接收基站发送的能够确定寻呼类型的寻呼消息,所述寻呼类型包括接入网发起的接入网寻呼或核心网发起的核心网寻呼。
这里,核心网寻呼通常是核心网针对激活态(如RRC_CONNECTED)的终端发起的寻呼,接入网寻呼通常是基站针对非激活态的终端发起的寻呼。当然,核心网寻呼也需要通过基站转发给终端。本发明实施例中基站发送的寻呼消息能够用于确定该寻呼消息对应的寻呼类型,具体的,基站可以通过寻呼消息,显式或隐式指示寻呼类型。
步骤32,所述终端确定所述寻呼消息对应的寻呼类型。
步骤33,在所述寻呼消息对应的寻呼类型为核心网寻呼时,所述终端将本终端的非接入NAS层和无线资源控制RRC层的状态更新为空闲态,并响应所述寻呼消息。
通过以上步骤,本发明实施例中,当Inactive态的终端接收到核心网寻呼时,将自身NAS层和RRC层都更新为空闲态,从而可以按照空闲态下定义的终端行为,对寻呼消息进行响应,避免了因为网络与终端对终端状态理解不一致所导致的寻呼问题。
本发明实施例中,如果在上述步骤32中,确定所述寻呼消息对应的寻呼类型为接入网寻呼时,则所述终端可以直接响应所述寻呼消息,发起连接恢复、建立或重建过程。例如,所述终端直接在RRC层响应所述寻呼消息,发起连接恢复、建立或重建过程,后续寻呼响应过程可以参考现有技术,此处不再赘述。
本发明实施例中,基站可以通过显式方式或隐式方式,指示寻呼类型。下面对本发明实施例可以采用的指示方式进行举例说明,当然,本发明实施例还可以采用以下方式以外的其他任何能够指示终端寻呼类型的方式。
1)显式指示
基站在所述寻呼消息携带所述寻呼类型的指示信息,此时,在步骤32中,所述终端根据所述指示信息,可以确定所述寻呼消息对应的寻呼类型。
例如,通过特定的1bit的指示位的值进行指示,如值为0时代表接入网寻呼,值为1时代表核心网寻呼。终端通过读取该指示位的值,即可确定寻呼类型。
2)隐式指示
2.1)基站在所述寻呼消息中携带有按照预先确定的表达方式表示的预设参数,且所述预设参数的不同表达方式对应于不同的寻呼类型。此时,在步骤32中,所述终端确定所述寻呼消息中的预设参数的表达方式所对应的寻呼类型,可以得到所述寻呼消息的寻呼类型。
例如,接入网寻呼和核心网寻呼分别使用终端不同的寻呼标识,接入网寻呼使用inactive UE ID或者resume ID,而核心网寻呼可以使用临时UE识别号(S-TMSI,S-Temporary Mobile Station Identity)或者国际移动用户识别码(IMSI,InternationalMobile Subscriber Identification Number)。终端根据寻呼消息中的终端寻呼标识的表达方式,可以确定寻呼类型。
2.2)基站在所述寻呼消息中携带或未携带第一预设参数,其中,所述寻呼消息是否携带第一预设参数是根据所述寻呼类型确定的。此时,在步骤32中,终端根据所述寻呼消息中是否携带所述第一预设参数,可以确定所述寻呼消息的寻呼类型。
例如,核心网寻呼携带核心网域参数,如CN-Domain参数,标识该寻呼是分组(PS)域还是电路(CS)域寻呼,而接入网寻呼不携带该参数。终端接收到寻呼消息后,根据寻呼消息中是否有该核心网域参数,确定寻呼类型为核心网寻呼或接入网寻呼。
在上述步骤33中,当所述寻呼消息为核心网寻呼时,终端需要将自身NAS层和RRC层的状态更新为空闲态,进而在空闲态下响应所述寻呼消息,执行对应的寻呼响应行为。例如,终端可以按照以下方式更新NAS层和RRC层的状态:
方式1:所述终端的RRC层,将RRC层状态更新为空闲态,并通知NAS层释放所述终端的连接,终端的NAS层根据所述通知将NAS层状态更新为空闲态;所述终端的RRC层将所述寻呼消息的寻呼内容递交给NAS层,所述NAS层接收所述寻呼内容并进行响应。
在上述方式1中,由RRC层作为主导,通知NAS层进行状态更新,并将寻呼消息的寻呼内容递交给NAS层,以在空闲态下进行寻呼消息的响应过程。
方式2:所述终端的RRC层,将所述寻呼消息的寻呼内容递交给NAS层,以及,将RRC层状态更新为空闲态;所述终端的NAS层,接收到所述寻呼内容后,将NAS层状态更新为空闲态,以及,响应所述寻呼内容。
在上述方式2中,NAS层收到RRC层递交的寻呼内容后,将自身状态更新为空闲态,进而可以在空闲态下进行寻呼消息的响应过程。
以上状态的更新,可以通过更新层中对应的状态机的状态来实现。在状态机的不同状态下,终端可以执行对应状态下的行为,例如,对寻呼消息进行响应,具体行为可以参考现有标准的相关定义,本文不再赘述。
需要指出的是,以上更新方式仅为本发明实施例可以采用的部分实现方式,终端也可以按照以上方式之外的其他方式进行状态更新,此处不再一一举例说明。
请参照图4,本发明实施例提供的寻呼方法,在应用于基站侧时,包括:
步骤41,基站在需要发起对终端的寻呼时,确定该寻呼的寻呼类型,所述寻呼类型包括接入网发起的接入网寻呼或核心网发起的核心网寻呼。
这里,基站可以根据寻呼的发起者,来确定寻呼为核心网寻呼或接入网寻呼。
步骤42,基站向所述终端发送能够确定寻呼类型的寻呼消息。
这里,可以参照上文的显式或隐式的指示方式,通过寻呼消息向终端指示寻呼类型。
例如,在显式指示时,所述寻呼消息携带有所述寻呼类型的指示信息。此时,在上述步骤42中,所述基站可以向所述终端发送携带有所述寻呼类型的指示信息的寻呼消息。
例如,在隐式指示时,所述寻呼消息中可以携带有按照预先确定的表达方式表示的预设参数,且所述预设参数的不同表达方式对应于不同的寻呼类型。此时,在上述步骤42中,所述基站根据所述寻呼类型,确定预设参数的表达方式,其中,所述预设参数的不同表达方式对应于不同的寻呼类型;然后,所述基站向所述终端发送寻呼消息,所述寻呼消息携带有按照所确定的表达方式表示的所述预设参数。
又例如,在隐式指示时,所述寻呼消息中可以携带或未携带第一预设参数,其中,所述寻呼消息是否携带第一预设参数是根据所述寻呼类型确定的。此时,在上述步骤42中,所述基站根据所述寻呼类型,确定所述寻呼消息是否携带第一预设参数;然后,所述基站向所述终端发送携带或未携带第一预设参数的寻呼消息。
从上文可以看出,本发明实施例中,基站在发送的寻呼消息中指示寻呼类型,处于非激活态的终端在收到寻呼消息后,将自身NAS层和RRC层都更新为空闲态,再对寻呼消息进行响应,从而可以保证网络侧与终端侧能够基于相同的终端状态完成终端的寻呼行为,避免了因网络与终端对终端状态理解不一致所导致的寻呼问题。
下面将进一步提供实现上述方法的基站和终端。
请参照图5,本发明实施例提供了一种终端,包括:
接收单元51,用于在本终端处于非激活态时,接收基站发送的能够确定寻呼类型的寻呼消息,所述寻呼类型包括接入网发起的接入网寻呼或核心网发起的核心网寻呼;
确定单元52,用于确定所述寻呼消息对应的寻呼类型;
第一响应单元53,用于在所述寻呼类型为核心网寻呼时,所述终端将本终端的非接入NAS层和无线资源控制RRC层的状态更新为空闲态,并响应所述寻呼消息。
作为一种实现方式,所述第一响应单元53可以包括:
位于RRC层的第一处理单元,用于将所述终端的RRC层状态更新为空闲态,并通知所述终端的NAS层释放所述终端的连接,以及,将所述寻呼消息的寻呼内容递交给NAS层;
位于NAS层的第二处理单元,用于根据所述第一响应单元的通知将NAS层状态更新为空闲态,以及,接收到第一处理单元递交的寻呼内容并进行响应。
作为另一种实现方式,所述第一响应单元53可以包括:
位于RRC层的第三处理单元,用于将所述寻呼消息的寻呼内容递交给NAS层,以及,将RRC层状态更新为空闲态;
位于NAS层的第四处理单元,用于接收到所述第三处理单元递交的所述寻呼内容后,将NAS层状态更新为空闲态,以及,响应所述寻呼内容。
这里,上述终端还可以包括:第二响应单元,用于在所述寻呼类型为接入网寻呼时,所述终端直接响应所述寻呼消息,发起连接恢复、建立或重建过程。
具体的,所述第二响应单元可以包括:
位于RRC层的第五处理单元,用于在RRC层响应所述寻呼消息,发起连接恢复、建立或重建过程。
作为一种实现方式,所述寻呼消息携带有所述寻呼类型的指示信息。此时,所述确定单元52,具体用于根据所述指示信息,确定所述寻呼消息对应的寻呼类型。
作为另一种实现方式,所述寻呼消息中携带有按照预先确定的表达方式表示的预设参数,且所述预设参数的不同表达方式对应于不同的寻呼类型。此时,所述确定单元52,具体用于确定所述寻呼消息中的预设参数的表达方式所对应的寻呼类型,得到所述寻呼消息的寻呼类型。
作为又一种实现方式,所述寻呼消息中携带或未携带第一预设参数,其中,所述寻呼消息是否携带第一预设参数是根据所述寻呼类型确定的。此时,所述确定单元52,具体用于根据所述寻呼消息中是否携带所述第一预设参数,确定所述寻呼消息的寻呼类型。
请参照图6,本发明实施例提供了终端的另一种结构,包括:
第一收发机601,在第一处理器604的控制下接收和发送数据,具体的,可以接收基站发送的能够确定寻呼类型的寻呼消息,所述寻呼类型包括接入网发起的接入网寻呼或核心网发起的核心网寻呼。
第一处理器604,用于读取第一存储器605中的程序,执行下列过程:
根据第一收发机601接收到的寻呼消息,确定所述寻呼消息对应的寻呼类型;以及,在所述寻呼消息对应的寻呼类型为核心网寻呼时,所述终端将本终端的非接入NAS层和无线资源控制RRC层的状态更新为空闲态,并响应所述寻呼消息。
在图6中,总线架构(用第一总线600来代表)可以包括任意数量的互联的总线和桥,第一总线600将包括由第一处理器604代表的一个或多个处理器和第一存储器605代表的存储器的各种电路链接在一起。第一总线600还可以将诸如***设备、稳压器和功率管理电路等之类的各种其他电路链接在一起,这些都是本领域所公知的,因此,本文不再对其进行进一步描述。第一总线接口603在第一总线600和第一收发机601之间提供接口。第一收发机601可以是一个元件,也可以是多个元件,比如多个接收器和发送器,提供用于在传输介质上与各种其他装置通信的单元。经第一处理器604处理的数据通过第一收发机601和第一天线602在无线介质上进行传输,进一步,第一天线602还接收数据并将数据经由第一收发机601传送给第一处理器604。
第一处理器604负责管理第一总线600和通常的处理,还可以提供各种功能,包括定时,***接口,电压调节、电源管理以及其他控制功能。而第一存储器605可以被用于第一存储处理器604在执行操作时所使用的数据。具体的,第一处理器604可以是CPU、ASIC、FPGA或CPLD。
作为一种实现方式,第一处理器604还可以用于在判断出在所述寻呼消息对应的寻呼类型为核心网寻呼时,控制所述终端的RRC层,将RRC层状态更新为空闲态,并通知NAS层释放所述终端的连接,终端的NAS层将NAS层状态更新为空闲态;以及,控制所述终端的RRC层将所述寻呼消息的寻呼内容递交给NAS层,以及,控制所述NAS层接收所述寻呼内容并进行响应。
作为一种实现方式,第一处理器604还可以用于在判断出在所述寻呼消息对应的寻呼类型为核心网寻呼时,控制所述终端的RRC层,将所述寻呼消息的寻呼内容递交给NAS层,并将RRC层状态更新为空闲态;以及控制所述终端的NAS层,接收到所述寻呼内容后,将NAS层状态更新为空闲态,然后响应所述寻呼内容。
第一处理器604还可以用于在判断出在所述寻呼消息对应的寻呼类型为接入网寻呼时,可以直接响应所述寻呼消息,发起连接恢复、建立或重建过程。具体的,可以直接在RRC层响应所述寻呼消息,发起连接恢复、建立或重建过程。
作为一种实现方式,所述寻呼消息携带有所述寻呼类型的指示信息,第一处理器604可以根据所述指示信息,确定所述寻呼消息对应的寻呼类型。作为另一种实现方式,所述寻呼消息中携带有按照预先确定的表达方式表示的预设参数,且所述预设参数的不同表达方式对应于不同的寻呼类型,第一处理器604可以确定所述寻呼消息中的预设参数的表达方式所对应的寻呼类型,得到所述寻呼消息的寻呼类型。作为又一种实现方式,所述寻呼消息中携带或未携带第一预设参数,其中,所述寻呼消息是否携带第一预设参数是根据所述寻呼类型确定的,第一处理器604可以根据所述寻呼消息中是否携带所述第一预设参数,确定所述寻呼消息的寻呼类型。
请参照图7,本发明实施例提供了一种基站,包括:
确定单元71,用于在需要发起对终端的寻呼时,确定该寻呼的寻呼类型,所述寻呼类型包括接入网发起的接入网寻呼或核心网发起的核心网寻呼;
发送单元72,用于向所述终端发送能够确定寻呼类型的寻呼消息。
这里,所述寻呼消息携带有所述寻呼类型的指示信息,或者,所述寻呼消息中携带有按照预先确定的表达方式表示的预设参数,且所述预设参数的不同表达方式对应于不同的寻呼类型,或者,所述寻呼消息中携带或未携带第一预设参数,其中,所述寻呼消息是否携带第一预设参数是根据所述寻呼类型确定的。
请参照图8,本发明实施例提供了基站的另一种结构,包括:
第二收发机801,在第二处理器804的控制下接收和发送数据,具体的,可以向终端发送能够确定寻呼类型的寻呼消息。
第二处理器804,用于读取第二存储器805中的程序,执行下列过程:
在需要发起对终端的寻呼时,确定该寻呼的寻呼类型,所述寻呼类型包括接入网发起的接入网寻呼或核心网发起的核心网寻呼;以及,控制所述第二收发机801向所述终端发送能够确定寻呼类型的寻呼消息。
在图8中,总线架构(用第二总线800来代表)可以包括任意数量的互联的总线和桥,第二总线800将包括由第二处理器804代表的一个或多个处理器和第二存储器805代表的存储器的各种电路链接在一起。第二总线800还可以将诸如***设备、稳压器和功率管理电路等之类的各种其他电路链接在一起,这些都是本领域所公知的,因此,本文不再对其进行进一步描述。第二总线接口803在第二总线800和第二收发机801之间提供接口。第二收发机801可以是一个元件,也可以是多个元件,比如多个接收器和发送器,提供用于在传输介质上与各种其他装置通信的单元。经第二处理器804处理的数据通过第二收发机801和第二天线802在无线介质上进行传输,进一步,第二天线802还接收数据并将数据经由第二收发机801传送给第二处理器804。
第二处理器804负责管理第二总线800和通常的处理,还可以提供各种功能,包括定时,***接口,电压调节、电源管理以及其他控制功能。而第二存储器805可以被用于第二存储处理器804在执行操作时所使用的数据。具体的额,第二处理器804可以是CPU、ASIC、FPGA或CPLD。
综上,本发明实施例提供的寻呼方法、基站及终端,在寻呼非激活态的终端的过程中,可以解决当网络与终端对终端状态理解不一致时所导致的终端寻呼失败问题,使终端可以正确接收到寻呼,提高了寻呼成功率。
以上所述是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明所述原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。