一种用户的接入方法与流程

本申请涉及通信技术，特别涉及一种用户的接入方法。

背景技术：

在lte系统中，寻呼的基本机制是：enodeb广播寻呼消息，消息中携带完整的pagingrecordlist，每一个pagingrecord中包含了被寻呼的ue的标志ue-identity(ueid)。ue会在寻呼时刻(po)上醒来监听并检测到使用p-rnti加扰的pdcch，ue读取pagingrecordlist中的每一个pagingrecord中的ue-identity。如果ue发现自己的ue标志与某个ue-identity一致，就会把ue-identity和cn-domain发往上层继续处理。如果ue没有找到一个与其ue标志一致的ue-identity，ue会丢弃接收到的paging消息，并进入休眠。

目前，在5gnewradio(nr)系统研究中，引入了波束扫描的概念，ran2已经同意采用波束扫描广播寻呼消息。然而，如果在波束扫描中发送寻呼消息中的整个pagingrecordlist，那么下行无线资源开销会迅速增加。为了降低下行无线资源开销，提出了response-driven寻呼的方案，该方案的中心思想是：gnodeb通过波束扫描方式给ue发送pis(pagingindicators)，ue收到包含pis的寻呼消息时，和网络联系来看它是否是真正的被寻呼。

pis可以认为是pagingrecordlist的压缩，目前有以下压缩方案，一个是使用裁剪的ueid；一个是使用一个groupid代替ueid。采用其他的压缩方案也是可行的。每一个压缩结果认为是一个pi，在寻呼广播中仅需要包含pis即可，而不是完整的pagingrecordlist，那么下行寻呼开销可降低。例如，一个pi是14比特，而一个ueid是40比特，那么下行寻呼开销大约会降低三倍。

接收到寻呼广播的ue判断自己是否和pis匹配，匹配上某个pi的ue发送msg1来响应gnodeb，这样gnodeb就知道了ue在小区的位置信息以及最适合的波束信息，后续gnodeb仅在指定波束上发送寻呼消息即可。response-driven寻呼主要存在以下两种实现方案，每个方案又包含两个子方案。

方案1：ue将自己的ueid发送给网络，由网络侧负责检查该ue是否被寻呼。具体地，方案1主要包含两种子方案，分别如图1a和图1b所示：

子方案1-1：ue通过msg1(携带rachpreamble和ueid)将ueid发送给网络侧；

子方案1-2：ue通过msg3(rrcconnectionrequestmessage)将ueid发送给网络侧。

方案2：ue通过msg1响应gnodeb，gnodeb发送包含ueid列表的rar给响应pi的ue(仅在收到msg1的指定波束内发送)，由ue完成ueid的检查，确认是否被寻呼。具体地，方案2主要包含以下两种子方案，分别如图2a和图2b所示：

子方案2-1：在msg2中携带ueid列表，但是未携带ulgrant信息，被寻呼的ue执行正常的随机接入过程来接收呼叫或者数据转发请求。

子方案2-2：在msg2中携带ueid列表和ulgrant信息，被寻呼的ue直接发起rrc连接建立请求。

对于方案2，有两种方式分配rachpreamble：

(1)给所有响应pis的ue分配一个公共的preamble。在此情况下，需在每个msg2携带完整的pagingrecordlist；

(2)对于每一个pi分配一个专有的preamble，在此情况下，仅需在每个msg2携带与专有preamble对应的ueid列表。

整体上，分配专有preamble的方案比分配公共preamble的下行开销要低。

方案2的实现主要取决于macpdu(rar)的设计。ran2关于macpdu(rar)最新的设计如图3所示。一个macpdu包含一个或多个macsubpdu，每个macsubpdu包含下面的一个：

-仅有一个bi(backoffindicator)的macsubheader；

-仅有一个随机接入preambleid(rapid)的macsubheader(也就是si请求的确认)；

-一个rapid的macsubheader和一个macrar。

对于上述两个方案，各自都存在一些问题。

在方案1中，不需要发送完整的pagingrecordlist，可以降低下行无线资源。但是由于与pi匹配的所有ue都需要通过随机接入过程将自身的ueid发送给gnodeb，因此会增加某些ue的功耗，如一些经常不被唤醒的ue。在子方案1-1中，由于需要在msg1携带ueid，该方案实现难度较大，需要3gpp重新扩展msg1。在子方案1-2中，匹配上pi的ue均需要发起随机接入流程并在msg3中携带自己的ueid，信令开销较大，且会增加不被寻呼ue的功耗。

在方案2中，需要在响应pi的波束中发送完整的pagingrecordlist或者指定preamble对应的完整ueid列表(取决于是给所有响应pis的ue分配一个公共的preamble还是给每一个pi分配一个专有的preamble)，实际测试中发现下行无线资源开销较大。

技术实现要素：

本申请提供一种用户的接入方法，能够减小下行无线资源的开销，同时实现简单。

为实现上述目的，本申请采用如下技术方案：

一种用户的接入方法，包括：

ue在其所在波束上检测寻呼消息，所述寻呼消息中携带至少一个寻呼指示pi和各个pi对应的专有preamble的前导码以及随机接入的prach信道资源；其中，位于同一波束上的寻呼消息中的pi，对应的所述prach信道资源相同；

当所述ue匹配上所述寻呼消息中的任一pi时，所述ue在任一pi对应的所述prach信道资源上，使用所述任一pi对应的专有preamble发送随机接入请求，以响应所述任一pi；

所述gnodeb接收ue响应pi的随机接入请求消息，并在有ue响应的波束上发送rar消息，并在所述rar消息中携带ue响应pi的rapid及其对应的ueid信息；

所述ue读取rar消息，并根据其中携带的所述rapid和对应的ueid信息进行ueid的检查，确认是否真正被寻呼；当确认真正被寻呼时，所述ue接入网络进行数据传输。

较佳地，当所述寻呼消息中的pi为裁减的ueid时，所述rar消息中携带的ueid信息为所述rapid对应的ueid列表中除所述裁减的ueid外剩余的ueid信息。

较佳地，确定所述各个寻呼指示对应的随机接入的prach信道资源的方式包括：

预先针对各个波束设置寻呼指示pi对应的prach信道资源；

根据寻呼指示所在的波束，将针对该波束所设置的寻呼指示对应的prach信道资源作为相应寻呼指示对应的prach信道资源。

较佳地，所述rar消息所在的macpdu包括至少一个用于寻呼的mac子pdu；

其中，所述用于寻呼的mac子pdu包括：mac子头和一个寻呼的macrar；所述mac子头包括：用于指示本mac子pdu类型的域、用于指示随机接入前同步码的rapid域和用于指示所述寻呼的macrar所占用字节数的长度域；所述寻呼的macrar中携带所述rapid对应的ueid信息。

较佳地，所述用于指示本mac子pdu类型的域包括2比特，利用2比特的四种取值指示四种mac子pdu类型；

所述四种mac子pdu类型包括：仅有一个bi的mac子头的mac子pdu、仅有一个rapid的mac子头的mac子pdu、包括一个rapid的mac子头和一个macrar的mac子pdu、包括一个rapid的mac子头和一个寻呼的macrar的用于寻呼的mac子pdu。

较佳地，在发送所述rar消息前，该方法进一步包括：

确定是否在所述rar消息中携带上行授权ulgrant信息；

当确定携带所述ulgrant信息时，在所述rar消息中携带所述ulgrant信息；所述ue在根据所述rar消息确认真正被寻呼时，根据所述ulgrant信息直接发起rrc连接建立过程；

当确定不携带所述ulgrant信息时，所述ue在根据所述rar消息确认真正被寻呼时，直接发起随机接入过程。

较佳地，在确定是否在所述rar消息中携带上行授权ulgrant信息时，根据所述ue的优先级和/或当前网络状况和/或所述ue响应的pi对应的ue个数进行。

较佳地，当ue的优先级高于设定的优先级阈值时，和/或，当当前网络负载低于设定的负载阈值时，和/或，当所述ue响应的pi对应的ue个数小于设定的个数阈值时，确定在所述rar消息中携带ulgrant信息。

较佳地，所述rar消息所在的macpdu包括至少一个用于寻呼的mac子pdu；

其中，所述用于寻呼的mac子pdu包括：mac子头和一个寻呼的macrar；所述mac子头包括：用于指示本mac子pdu类型的域、用于指示随机接入前同步码的rapid域、用于指示所述寻呼的macrar所占用字节数的长度域和用于指示是否携带ulgrant信息的格式域；所述寻呼的macrar中携带所述rapid对应的ueid信息；当所述用于指示是否携带ulgrant信息的格式域指示携带所述ulgrant信息时，所述寻呼的macrar中携带所述rapid对应的ueid信息，并携带每个ueid信息对应的ulgrant信息。

由上述技术方案可见，本申请中，ue检测寻呼消息，寻呼消息中携带至少一个寻呼指示pi和各个寻呼指示对应的专有preamble的前导码索引以及随机接入的prach信道资源索引；其中，同一波束上的寻呼消息中的pi对应相同的prach信道资源；当ue匹配上寻呼消息中的任一pi时，ue在该pi对应的prach信道资源上，使用专有preamble发送随机接入请求，以响应pi；gnodeb接收ue发送的随机接入请求消息，在该ue所在的波束上发送rar消息，并在rar消息中携带ue响应pi的rapid及其对应的ueid信息；ue读取rar消息，并根据其中携带的rapid和对应的ueid信息进行ueid的检查，确认是否真正被寻呼；当确认真正被寻呼时，ue接入网络进行数据传输。通过上述处理，在同一个波束中响应pi的所有ue使用相同的prach资源，这样在gnodeb反馈随机接入响应时可以针对这些在同一波束的ue复用macpdu，以大大降低下行开销，且不需要修改原有消息，实现简单。

附图说明

图1a为response-driven寻呼(ue携带ueid给gnodeb)中子方案1-1的基本流程示意图；

图1b为response-driven寻呼(ue携带ueid给gnodeb)中子方案1-2的基本流程示意图；

图2a为response-driven寻呼(gnodeb携带ueids给ue)中子方案2-1的基本流程示意图；

图2b为response-driven寻呼(gnodeb携带ueids给ue)中子方案2-2的基本流程示意图；

图3为macpdu(randomaccessresponse)的格式示意图；

图4为本申请中用户接入方法的基本流程示意图；

图5a～图5d分别为本申请中随机接入响应的macsubheader的四种类型示意图；

图6为本申请中示例性macpdu(rar)格式的示意图；

图7为本申请中示例性macrarofpaging的设计示意图；

图8为本申请中引入f域后的mac子头示意图；

图9a为f＝1时macrarofpaging的内容示意图；

图9b为f＝0时macrarofpaging的内容示意图。

具体实施方式

为了使本申请的目的、技术手段和优点更加清楚明白，以下结合附图对本申请做进一步详细说明。

对于背景技术中描述的方案2，这里分析一下造成下行无线资源开销较大的原因：在方案2中，需要在响应pi的波束中发送完整的pagingrecordlist或者指定preamble对应的完整ueid列表(取决于是给所有响应pis的ue分配一个公共的preamble还是给每一个pi分配一个专有的preamble)，基于这一处理可见，下行开销的大小取决于响应pi的波束的个数。如果响应pi的ue分布在不同的波束，那么对下行开销影响较大。同时，方案2中响应pi的同一个波束的ue可能会使用不同的prach信道资源，也就是ra-rnti不一样，macpdu不能复用，因此也会增加下行无线资源开销。

基于上述原因的分析，本申请中，在背景技术中方案2的基础上，对于在同一波束中响应pi的ue使用相同的prach资源，从而能够复用macpdu，减少下行资源开销。进一步地，在rar中可以不发送包括完整ueid的ueid列表或pagingrecordlist，而是发送指定preamble对应的剩余的ueid列表，从而可以进一步减少发送rar占用的下行资源开销。

图4为本申请中用户接入方法的基本流程图。如图4所示，该方法包括：

步骤401，ue检测寻呼消息。

在寻呼消息中携带至少一个寻呼指示(pi)和各个pi对应的专有随机接入前导码以及随机接入的prach信道资源。其中，预先为每个pi分配一个专有的preamble，在寻呼消息中针对每个pi携带为其分配的专有preamble。对于随机接入的prach信道资源，在同一波束上发送的各个寻呼消息中的pi，其对应的prach信道资源相同，这样，同一波束上的ue采用相同的prach信道资源，从而能够在gnodeb反馈随机接入响应(rar)消息时，这些ue复用相同的macpdu。其中，在寻呼消息中，确定寻呼指示对应的prach信道资源的方式可以为：预先针对各个波束设置寻呼指示对应的prach信道资源；根据寻呼指示所在的波束，将针对该波束所设置的寻呼指示对应的prach信道资源作为发送preamble使用的prach信道资源。

具体地，ue在指定时刻醒来监听并检测到使用p-rnti加扰的pdcch后，ue读取其所在波束的寻呼消息，寻呼消息中包含一组pagingrecordlist，在每一个pagingrecord中包括一个pi(具体可以是裁剪的ueid)及对应的专有随机接入前导码索引和随机接入prach信道资源索引。具体专有随机接入前导码索引和随机接入prach信道资源索引的指示方式在下文中进行详述。pi指示ue需要响应网络来判断自己是否真正被寻呼，每个pi至少对应一个pagingueid。为降低下行资源开销，在同一波束上发送的寻呼消息中的pi，其对应的prach信道资源是相同的，也就是说，同一波束上发送的寻呼消息中的pi，其对应的ra-rnti是相同的。

步骤402，当ue匹配上检测到的寻呼消息中的某个pi时，ue在该pi对应的prach信道资源上，使用该pi对应的preamble发送随机接入请求，以响应相应的pi。

ue根据寻呼消息中携带的pi进行匹配，匹配上某个pi的ue在寻呼消息指定的该pi对应的prach信道资源上，使用指定的preamble发起随机接入。这里，由于在步骤401中，同一个波束上发送的寻呼消息中的pi，其对应的ra-rnti是相同的，因此，本步骤中，在同一个波束上响应pi的ue将会使用相同的prach信道资源。

步骤403，gnodeb接收ue响应pi的随机接入请求消息，在存在ue响应的波束上发送rar消息，并在rar消息中携带ue响应pi的rapid及其对应的ueid信息。

gnodeb收到msg1(即随机接入请求消息)后，也就知道了ue所在的波束位置。gnodeb仅在有ue响应的波束上，将在该波束上响应pi的rapid及与其对应的ueid信息封装在rar消息中发送给ue。具体rar消息的具体格式在下文中进行详述。在前述步骤401和402中，位于同一波束上的pi对应相同的prach信道资源，因此，本步骤中，在同一个波束上可以有多个pi响应，则位于同一波束上的多个pi对应的rapid及与其对应的ueid信息具有相同的ra-rnti，可复用同一个macpdu。

更详细地，为进一步降低下行资源开销，当步骤401中的pi为裁减的ueid时，rar消息中携带的ueid信息可以不是完整的ueid，而是完整的ueid除去裁减的ueid之外剩余的ueid信息。

步骤404，ue读取rar消息，并根据其中携带的rapid和对应的ueid信息进行ueid的检查，确认是否真正被寻呼；当确认真正被寻呼时，ue接入网络进行数据传输。

至此，本申请中的基本方法流程结束。

在上述步骤401中，寻呼消息中携带寻呼指示及其对应的随机接入码和随机接入prach信道资源。可以重新设计寻呼消息的具体格式用于携带上述信息，下面给出一个寻呼消息的示例性格式。该示例性的寻呼消息格式将在已有的寻呼消息上进行优化，gnodeb负责对每个pi使用的preamble码以及用于发送preamble的信道资源进行配置，并封装在寻呼消息中一同发给ue。

具体地，在示例性的寻呼消息中包含一组pagingrecordlist，而在每一个pagingrecord中，包含一个裁剪的ueid(即pi)及对应的ra-preambleindex和ra-prach-beamindex。其中，裁剪的ueid用于ue的匹配，ra-preambleindex用于指示随机接入码，ra-prach-beamindex用于指示随机接入的prach信道资源。匹配成功的ue根据ra-preambleindex和ra-prach-beamindex发起随机接入使用。鉴于此，对寻呼消息进行如下的修改：

其中，ue-identity表示被寻呼ue的裁剪的ueid，用于ue侧ueid的匹配，以判断是否需要响应该寻呼消息；truncated_s-tmsi表示裁剪的s-mtsi，即一个pi；ra-preambleindex表示发送preamble码所使用的前导码索引(即随机接入前导码)，专有preamble是为每个裁剪的ueid(即pi)配置的一个专有的preamble，用于区分后续的msg1是正常的随机接入还是本申请中步骤402发起的随机接入。ra-prach-beamindex表示ue在所在波束上发送ra-preambleindex使用的prach信道资源索引，其中，同一波束上发送的ra-prach-beamindex相同。

在lte中，寻呼消息中的pagingrecordlist的ueid信息一般为s-tmsi。若pagingid是imsi，则表示本次寻呼是一次异常呼叫，用于网络侧的错误恢复，此情况下不建议使用本文的寻呼方案。

由于s-tmsi＝mmec+m-tmsi，其中，mmec是mme的编码，是8比特；m-tmsi是mme给终端分配的随机编号，是32比特。相较于使用s-tmsi的公共部分mmec(如果被寻呼ueid是在同一范围内，mmec比特差异不大)，显然m-tmsi更能表示ue之间的多样性信息。因此，对于ueid是s-tmsi的情况，我们建议使用m-tmsi中的比特信息作为裁剪的寻呼ueid信息，为了方便操作，建议使用m-tmsi的后面几位比特作为裁剪的ueid。

在上述步骤403中，同一波束上发送的rar，其使用的prach资源相同，因此可以复用同一个macpdu。下面给出一个示例性的macpdu格式，可以用于复用同一波束上发送的多个rar。

在本申请示例性的macpdu格式中，可以根据ran2最新的macpdu设计，在macsubpdu(rapidandrar)的基础上，新增用于寻呼的macsubpdu(rapidandrar)，称之为macsubpdu(rapidandrarofpaging)。具体地，一个macpdu包含一个或多个macsubpdu，每个macsubpdu包含下面的一个：

-仅有一个bi(backoffindicator)的macsubheader；

-仅有一个rapid的macsubheader(也就是si请求的确认)；

-一个rapid的macsubheader和一个macrar；

-一个rapid的macsubheader和一个macrarofpaging。

其中的“一个rapid的macsubheader和一个macrarofpaging”就是新增的用于寻呼的macsubpdu。

对于mac子头(macsubheader)，可以新增用于指示本mac子pdu类型的域和用于指示寻呼的macrar所占用字节数的域。在本示例性的macpdu格式中，利用扩展域(e)和类型域(t)联合指示本mac子pdu类型，利用长度域(l)指示寻呼的macrar所占用的字节数。

具体地，对于macsubheader的设计，可以设置t域、r域、bi域、rapid域以及可选的l域。每个域的具体含义如下：

-e:扩展域，长度为1比特。如果e域置为“0”，表示仅有一个subheader，指示bisubheader或者si请求的subheader；如果e域置为“1”，表示包含macrar的subheader，指示rapid和rar的subheader，或者rapid和rarofpaging的subheader。具体的含义需要结合t域进一步判断。

-t:类型域，长度为1比特。如果e域置为“0”：t域置为“0”时，指示macsubpdu(bionly)类型，t域置为“1”时，指示macsubpdu(rapidonly)类型。如果e域置为“1”：t域置为“0”，指示macsubpdu(rapidandrar)类型，如果t域置为“1”，指示macsubpdu(rapidandrarofpaging)类型。

-r:预留比特。

-bi:backoff指示域表明小区处于过载状态。bi域的长度为4bits。

-rapid:随机接入前同步码标识域指明了已发送的随机接入前同步码，rapid域的长度为6bits。

-l:长度域，指示对应的macrarofpaging单元的字节数。当且仅当e域和t域均置为“1”时，l域才存在。

综上，随机接入响应的macsubheader共包含四种类型，分别如图5a～图5d所示。基于上述macsubheader的设计，改进的macpdu(rar)格式可以如图6所示，包含四种macsubpdu类型：macsubpdu(bionly)、macsubpdu(rapidonly)、macsubpdu(rapidandrar)和macsubpdu(rapidandrarofpaging)。

在用于寻呼的mac子pdu中，用于寻呼的macrar需要携带rapid对应的ueid信息，因此需要重新设计。一般认为ueid为s-tmsi，总共40比特，举例中，将s-tmsi的后8位比特作为裁剪的ueid(即pi)在寻呼消息中发送，那么剩余的32个比特需要在macrarofpaging中携带，如果一个pi对应的真正被寻呼ue的数目为m个，macrarofpaging的设计可以如图7所示。

基于上述macpdu格式，在步骤403发送的rar消息中携带rapid及其对应的ueid信息，因此，该rar消息所在macpdu包括至少一个用于寻呼的mac子pdu。

在背景技术描述的方案2-2中，可以在gnodeb反馈给ue的rar消息中携带ulgrant信息，从而使ue在接收到rar消息后可以直接进行rrc连接建立，以提高传输效率。然而如果在响应pi的每个波束中，给该pi对应的每个真正被寻呼的ue都配置ulgrant，会造成资源分配的浪费，这是因为真正被寻呼的ue仅存在于响应波束的一个或多个。基于此，可以在本申请图4所示的方法中，在步骤403的rar消息中携带ulgrant信息。同时，为了在传输效率和资源分配上达到一个平衡，本申请提出一种可配置的方案，也就是在rar消息中可选是否携带ulgrant信息，是否携带授权信息由gnodeb根据实际情况来决定。具体地，可以根据ue的优先级和/或当前网络状况和/或ue响应的pi对应的ue个数，确定是否携带ulgrant信息。

更详细地，在前述步骤403中，当网络资源紧张(例如网络负载大于或等于设定的负载阈值)，或者一个pi对应的ue数目较多(例如大于或等于设定的个数阈值)，或者ue的优先级较低(例如优先级小于或等于设定的优先级阈值)时，可以在rar消息中不携带ulgrant信息，ue接收相应的rar消息后，发起正常的随机接入过程。在前述步骤403中，当网络资源富足(例如网络负载低于设定的负载阈值)，或者一个pi对应的ue数目较少(例如ue数目小于设定的个数阈值)，或者ue的优先级较高(例如优先级大于设定的优先级阈值)时，可以在rar消息中携带ulgrant信息，ue接收相应的rar消息后，根据ulgrant信息直接发起rrc连接建立过程。

以上两种情况在网络中可同时存在或者单独存在。可以在rar消息中携带是否包括ulgrant信息的指示信息a，ue根据该指示信息a确定rar消息中是否携带ulgrant信息。

为实现在rar消息中携带指示信息a和ulgrant信息，还需要对用于寻呼的mac子pdu增加新的域。例如，可以在前述用于寻呼的mac子pdu的mac子头的基础上，保留e域、t域、r域、bi域和rapid域，新增f域(格式域)用于指示寻呼的macrar中是否携带ulgrant信息。f域的含义可以如下：

f:格式域，指示macrarofpaging中是否携带ulgrant等信息，f域长度为1bit。置为“0”时，表示不携带ulgrant等信息，置为“1”时，表示携带ulgrant等信息。

改进后的mac子头如图8所示。根据f域的取值不同，对应的macrarofpaging内容不同，如图9a和图9b所示。假设一个pi对应的真正被寻呼ue数为m个，分配给ue的ulgrant等信息这部分参考lte中macrar的设计，由4个字段组成：r/timingadvancecommand/ulgrant/temporaryc-rnti，总共6个字节信息。那么f＝1时macrarofpaging的内容可以如图9a所示，f＝0时macrarofpaging的内容可以如图9b所示。

上述即为本申请中用户接入方法的具体实现。

本文提出的方案1和方案2相较于上述的方案1，不增加上行信令的开销，同时不需要重新扩展msg1，实现较为简单。

上述本申请中的用户接入方法主要是在背景技术中方案2的基础上进行优化，相较于方案2，会在寻呼消息中携带每个preambleindex对应的prach资源信息，使得在一个波束中响应多个pi的ue使用相同的prach资源(也就是ra-rnti值一样)，可以复用macpdu，从而节省下行资源开销。进一步地，gnodeb在收到msg1后无需发送完整的pagingrecordlist或者指定preamble对应的完整ueid列表，而是发送指定preamble对应的剩余的ueid列表，进一步降低了下行开销。

另外，本申请提供的用户接入方法，还可以根据实际情况决定是否在rar消息中配置ulgrant，从而能够进一步提高传输效率。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。