寻呼处理方法及装置 |
|||||||
| 申请号 | CN201510652611.9 | 申请日 | 2015-10-10 | 公开(公告)号 | CN106572534A | 公开(公告)日 | 2017-04-19 |
| 申请人 | 中兴通讯股份有限公司; | 发明人 | 杜婷; | ||||
| 摘要 | 本 发明 提供了一种寻呼处理方法及装置，其中，寻呼处理方法包括：获取用户所处的寻呼时机；在确定寻呼时机为子 帧 4和/或9的情况下，采用子帧0和/或5寻呼用户；通过本发明，解决了相关技术中的子帧配置无法满足传输技术中的特殊需求的问题，将更多的子帧配置成为满足特殊需求的特别子帧，提高了子帧资源利用率。 | ||||||
| 权利要求 | 1.一种寻呼处理方法，用于频分双工FDD模式，其特征在于，包括： |
||||||
| 说明书全文 | 寻呼处理方法及装置技术领域[0001] 本发明涉及通信领域，具体而言，涉及一种寻呼处理方法及装置。 背景技术[0002] 为了减少功率消耗，用户UE会在空闲模式下使用不连续接收(Discontinuous Reception，简称DRX)。一个寻呼时机(Paging Occasion，简称PO)是一个寻呼无线网络临时标识(Paging-Radio Network Temporary Identifier，简称P-RNTI)可能在物理下行控制信道(Physical Downlink Control CHannel，简称为PDCCH)上发送寻址此寻呼(paging)消息的子帧。一个寻呼帧(Paging Frames，简称PF)是一个无线帧，其中包含了一个或者多个寻呼时机。当DRX使用，UE只能在每个不连续接收周期(DRX cycle)监控一个PO。 [0003] PF由公式(1)给出： [0004] SFN mod T＝(T div N)*(UE_ID mod N) (1) [0005] 表1是FDD模式的寻呼子帧图案表，如表1所示，寻呼子帧图案中指向PO的索引号i_s可以由公式(2)计算： [0006] i_s＝floor(UE_ID/N)mod Ns (2) [0007] 无论DRX参数什么时候在系统信息(System Information，简称SI)中改变，系统消息DRX参数存储在UE中应被本地更新。如果UE没有国际移动用户识别码(International Mobile Subscriber Identification Number，简称IMSI)，比如没有全球用户识别卡(Universal Subscriber Identity Module，简称USIM)时发起紧急呼叫，UE应在PF以及i_s公式中使用缺省的标识UE_ID＝0。 [0008] UE从系统信息块(System Information Block，简称SIB)2中获取DRX相关信息，然后根据DRX周期，UE监测PDCCH信道，查看是否有寻呼消息，如果PDCCH信道指示有寻呼消息，那么UE解调PCH信道去看寻呼消息是否属于自己。寻呼的通知由PDCCH DCI格式1C通知UE，PDCCH的通知上携带P-RNTI,表示其是寻呼消息。具体地，被寻呼的UE_ID承载在寻呼信道(Paging Channel，简称PCH)的寻呼消息中，PCH映射到物理下行共享信道(Physical Downlink Shared Channel，简称为PDSCH)信道上，UE_ID是IMSI或者是移动管理实体(Mobility Management Entity，简称MME)分配的临时移动用户标识(Serving-Temporary Mobile Subscriber Identity，简称S-TMSI)。为了降低RRC_IDLE态UE的电力消耗，UE使用不连续接收方式接收寻呼消息，RRC_IDLE态下的UE在特定的子帧监听PDCCH。这些特定的子帧称为PO。这些子帧所在的无线帧称为寻呼PF。与PF和PO相关的两个参数T和nB这两个参数由系统消息SIB2通知UE。 [0009] 根据公式(1)和(2)计算出PF和PO的具体位置后，UE开始监听相应子帧的PDCCH如果发现有P-RNTI则根据PDCCH指示的RB分配和调制编码方式从同一子帧的PDSCH上获取寻呼消息。如果寻呼消息含有本UE的ID则发起寻呼响应，否则在间隔T个无线帧后继续监听相应子帧的PDCCH。 [0010] 以下参数被使用在PF以及i_s的公式，如公式(1)和公式(2)中： [0011] T:UE的DRX周期。T由UE具体的DRX值的最小值确定，如果由高层分配，一个缺省的DRX值在系统广播消息中广播。如果UE具体的DRX不用高层分配，则此缺省值被应用。 [0012] nB:4T,2T,T,T/2,T/4,T/8,T/16,T/32。该参数主要表征了寻呼的密度4T表示每个无线帧有4个子帧用户寻呼T/4表示每4个无线帧有1个子帧用于寻呼，该值决定了系统的寻呼容量，从SIB2中读取。 [0013] N:min(T,nB)。 [0014] Ns:max(1,nB/T)。 [0015] UE_ID:IMSI mod 1024。 [0016] floor(UE_ID/N)：取不大于UE_ID/N的最大整数。 [0017] IMSI为10进制的整数，如：IMSI＝12(digit1＝1,digit2＝2),则应看为“12”，而不是“1*16+2＝18”。 [0018] 表1 [0019]Ns PO when i_s＝0 PO when i_s＝1 PO when i_s＝2 PO when i_s＝3 1 9 N/A N/A N/A 2 4 9 N/A N/A 4 0 4 5 9 [0020] 在SA1第69次会议提出了关于增强视频的需求，其中，提到了采取增强型多媒体广播组播业务(e-Multimedia Broadcast Multicast Service，简称eMBMS)作为增强视频的传输技术，但是eMBMS的资源利用率最多只能达到60％，因为对于一个无线帧而言，频分双工FDD(Frequency Division Duplex)模式下的子帧0,4,5,9是不能配置成多播广播单频网络(Multicast Broadcast Single Frequency Network，简称为MBSFN)子帧，子帧0,5承载着主信息块(Master Information Block，简称MIB)，系统信息块(System Information Block，简称SIB)1，主同步信号(Primary Synchronization Signal，简称PSS)，辅同步信号(Secondary Synchronization Signal，简称SSS)等重要信息，子帧0,4,5,9都是寻呼(paging)子帧承担着寻呼的作用。TDD模式下的子帧0，1，5，6不能配置成MBSFN子帧，子帧0,5承载着MIB，SIB1，SSS等重要信息，子帧1,6为特殊子帧承载着PSS等重要信息，并且0,1,5,6这四个子帧为paging子帧，承担着寻呼的作用。 [0021] 针对相关技术中，FDD模式下，相关技术中的子帧配置无法满足传输技术中的特殊需求的问题，目前尚未提出有效的解决方案。 发明内容[0022] 本发明提供了一种寻呼处理方法及装置，以至少解决FDD模式下，相关技术中的子帧配置无法满足传输技术中的特殊需求的问题。 [0023] 根据本发明的一个实施例，提供了一种寻呼处理方法，用于频分双工FDD模式，包括：获取用户所处的寻呼时机；在确定寻呼时机为子帧4和/或9的情况下，采用子帧0和/或5寻呼用户。 [0024] 在本发明实施例中，子帧4和/或9可作为多播组播单频网络MBSFN子帧使用。 [0025] 在本发明实施例中，在确定寻呼时机为子帧4和/或9的情况下，采用子帧0和/或5寻呼用户包括：在寻呼子帧图案中的i_s为1，NS为4的情况下，将i_s设置为0和/或2；和/或，在i_s为3，NS为4的情况下，将i_s设置为0和/或2；其中，i_s表示寻呼时机的索引号，NS表示1和Nb/T的较大值，Nb表示寻呼的密度，Nb为4*T，表示每个无线帧中有4个子帧可用于寻呼，T为用户的不连续接收周期；在i_s为0，NS为4的情况下，寻呼时机为子帧0；在i_s为1，NS为4的情况下，寻呼时机为子帧4；在i_s为2，NS为4的情况下，寻呼时机为子帧5；在i_s为3，NS为4的情况下，寻呼时机为子帧9；采用NS为4以及设置后的i_s所共同指示的寻呼时机寻呼用户。 [0026] 在本发明实施例中，采用子帧0和/或5寻呼用户之后，方法还包括：将寻呼时机相同的多个用户的寻呼内容合并成一条寻呼消息，将寻呼消息通过寻呼信道传输给多个用户。 [0027] 根据本发明的另一个实施例，提供了一种寻呼处理方法，用于频分双工FDD模式，包括：获取用户所处的寻呼时机；在寻呼时机为子帧4和/或9的情况下，在子帧0和/或5上监听寻呼消息。 [0028] 在本发明实施例中，子帧4和/或9可作为多播组播单频网络MBSFN子帧使用。 [0029] 在本发明实施例中，在寻呼时机为子帧4和/或9的情况下，在子帧0和/或5上监听寻呼消息包括：在i_s为1，NS为4的情况下，将i_s设置为0和/或2；在i_s为3，NS为4的情况下，将i_s设置为0和/或2；其中，i_s表示寻呼时机的索引号，NS表示1和Nb/T的较大值，Nb表示寻呼的密度，Nb为4*T，表示每个无线帧中有4个子帧用于监听寻呼，T为用户的不连续接收周期；在i_s为0，NS为4的情况下，寻呼时机为子帧0；在i_s为1，NS为4的情况下，寻呼时机为子帧4；在i_s为2，NS为4的情况下，寻呼时机为子帧5；在i_s为3，NS为4的情况下，寻呼时机为子帧9；在NS为4以及设置后的i_s所指示的寻呼时机上监听寻呼消息。 [0030] 在本发明实施例中，在子帧0和/或5上监听寻呼消息包括：监听子帧0和/或5的物理下行控制信道PDCCH；根据PDCCH所指示的资源块RB分配方式和调制编码MCS方式，在寻呼时机的物理下行共享信道PDSCH上获取寻呼消息。 [0031] 在本发明实施例中，在子帧0和/或5上监听寻呼消息之后，方法还包括：判断寻呼消息中是否含有用户的标识；如果是，则向用户所在的基站发送寻呼响应消息；如果否，则在预定时间后继续监听寻呼消息。 [0032] 根据本发明的另一实施例，提供了一种寻呼处理装置，位于网络侧中，用于频分双工FDD模式，包括：获取模块，用于获取用户所处的寻呼时机；寻呼模块，用于在确定寻呼时机为子帧4和/或9的情况下，采用子帧0和/或5寻呼用户。 [0033] 在本发明实施例中，子帧4和/或9可作为多播组播单频网络MBSFN子帧使用。 [0034] 在本发明实施例中，寻呼模块包括：设置单元，用于在寻呼子帧图案中的i_s为1，NS为4的情况下，将i_s设置为0和/或2；和/或，在i_s为3，NS为4的情况下，将i_s设置为0和/或2；其中，i_s表示寻呼时机的索引号，NS表示1和Nb/T的较大值，Nb表示寻呼的密度，Nb为4*T，表示每个无线帧中有4个子帧可用于寻呼，T为用户的不连续接收周期；在i_s为0，NS为4的情况下，寻呼时机为子帧0；在i_s为1，NS为4的情况下，寻呼时机为子帧4；在i_s为2，NS为4的情况下，寻呼时机为子帧5；在i_s为3，NS为4的情况下，寻呼时机为子帧9；寻呼单元，用于采用NS为4以及设置后的i_s所共同指示的寻呼时机寻呼用户。 [0035] 在本发明实施例中，装置还包括：传输模块，用于将寻呼时机相同的多个用户的寻呼内容合并成一条寻呼消息，将寻呼消息通过寻呼信道传输给多个用户。 [0036] 根据本发明的另一实施例，提供了一种寻呼处理装置，位于终端中，用于频分双工FDD模式，包括：获取模块，用于获取用户所处的寻呼时机；监听模块，用于在寻呼时机为子帧4和/或9的情况下，在子帧0和/或5上监听寻呼消息。 [0037] 在本发明实施例中，监听模块包括：设置单元，用于在i_s为1，NS为4的情况下，将i_s设置为0和/或2；和/或，在i_s为3，NS为4的情况下，将i_s设置为0和/或2；其中，i_s表示寻呼时机的索引号，NS表示1和Nb/T的较大值，Nb表示寻呼的密度，Nb为4*T，表示每个无线帧中有4个子帧用于监听寻呼，T为用户的不连续接收周期；在i_s为0，NS为4的情况下，寻呼时机为子帧0；在i_s为1，NS为4的情况下，寻呼时机为子帧4；在i_s为 2，NS为4的情况下，寻呼时机为子帧5；在i_s为3，NS为4的情况下，寻呼时机为子帧9；第一监听单元，用于在NS为4以及设置后的i_s所共同指示的寻呼时机上监听寻呼消息。 [0038] 在本发明实施例中，监听模块包括：第二监听单元，用于监听子帧0和/或5的物理下行控制信道PDCCH；获取单元，用于根据PDCCH所指示的资源块RB分配方式和调制编码MCS方式，在寻呼时机的物理下行共享信道PDSCH上获取寻呼消息。 [0039] 在本发明实施例中，装置还包括：判断模块，用于判断寻呼消息中是否含有用户的标识；发送模块，用于在是的情况下，向用户所在的基站发送寻呼响应消息；监听模块，还用于在否的情况下，在预定时间后继续监听寻呼消息。 [0040] 通过本发明，采用在寻呼时机为子帧4和/或9的情况下，采用子帧0和/或5寻呼用户或者在子帧0和/或5上监听寻呼消息，即通过修改子帧4和/或9，使得寻呼的任务由子帧0和/或5来承担，进而将子帧4和/或9空余成普通子帧，进而可以将空余出的子帧4和/或9配置成其他子帧，解决了相关技术中的子帧配置无法满足传输技术中的特殊需求的问题，将更多的子帧配置成为满足特殊需求的特别子帧，提高了子帧资源利用率。附图说明 [0041] 此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中： [0042] 图1是根据本发明实施例的寻呼处理方法的流程图一； [0043] 图2是根据本发明实施例的寻呼处理方法的流程图二； [0044] 图3是根据本发明实施例的寻呼处理方法的流程图三； [0045] 图4是根据本发明实施例的寻呼处理方法的流程图四； [0046] 图5是本发明优选实施例中的寻呼时机计算的流程示意图； [0047] 图6是本优选实施例的寻呼处理方法的流程示意图一； [0048] 图7是本优选实施例的寻呼处理方法的流程示意图二； [0049] 图8是本优选实施例的用户发起寻呼响应的流程示意图一； [0050] 图9是本优选实施例的寻呼处理方法的流程示意图三； [0051] 图10是本优选实施例的用户获取ETWS信息的流程示意图； [0052] 图11是根据本发明实施例的寻呼处理装置的结构框图一； [0053] 图12是根据本发明实施例的寻呼处理装置的结构框图二； [0054] 图13是根据本发明实施例的寻呼处理装置的结构框图三； [0055] 图14是根据本发明实施例的寻呼处理装置的结构框图四； [0056] 图15是根据本发明实施例的寻呼处理装置的结构框图五； [0057] 图16是根据本发明实施例的寻呼处理装置的结构框图六。 具体实施方式[0058] 下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。 [0060] 在本实施例中提供了一种寻呼处理方法，图1是根据本发明实施例的寻呼处理方法的流程图一，如图1所示，该流程包括如下步骤： [0061] 步骤S102，获取用户所处的寻呼时机； [0062] 步骤S104，在确定寻呼时机为子帧4和/或9的情况下，采用子帧0和/或5寻呼用户。 [0063] 通过上述步骤，采用在寻呼时机为子帧4和/或9的情况下，采用子帧0和/或5寻呼用户，即通过修改子帧4和/或9，使得寻呼的任务由子帧0和/或5来承担，进而将子帧4和/或9空余成普通子帧，进而可以将空余出的子帧4和/或9配置成其他子帧，进而解决了FDD模式下，相关技术中的子帧配置无法满足传输技术中的特殊需求的问题，将更多的子帧配置成为满足特殊需求的特别子帧，提高了子帧资源利用率。 [0064] 需要说明的是，上述方法可以应用于FDD模式下。 [0065] 需要说明的是，上述特殊需求可以是增强视频的需求，也可以是增强音频的需求，但并不限于此。 [0066] 在一个可选的实施例中，上述子帧4和/或9可以作为多播组播单频网络MBSFN子帧使用，即可以将子帧4和/或9配置成为MBSFN子帧，以满足增强视频的需求，能够提高MBSFN子帧的配置率，进而提高了eMBMS的资源利用率。 [0067] 在本发明实施例中，上述步骤S104中，在确定寻呼时机为子帧4和/或9的情况下，采用子帧0和/或5寻呼用户可以通过以下方式实现：在寻呼子帧图案中的i_s为1，NS为4的情况下，将i_s设置为0和/或2；和/或，在i_s为3，NS为4的情况下，将i_s设置为0和/或2；其中，i_s表示寻呼时机的索引号，NS表示1和Nb/T的较大值，Nb为4*T，表示每个无线帧中有4个子帧可用于寻呼，T为用户的不连续接收周期；在i_s为0，NS为4的情况下，寻呼时机为子帧0；在i_s为1，NS为4的情况下，寻呼时机为子帧4；在i_s为2，NS为4的情况下，寻呼时机为子帧5；在i_s为3，NS为4的情况下，寻呼时机为子帧9；采用NS为4以及设置后的i_s所指示的寻呼时机寻呼用户。即通过修改寻呼时机的索引号i_s来达到修改寻呼子帧配置的目的，通过该技术特征可以实现本该由子帧4寻呼的用户改由子帧0和/或子帧5来进行，本由子帧9寻呼的用户改由子帧5和/或子帧0进行，将子帧4和/或9空余出来，进而能够将空余出的子帧4和/或9配置成MBSFN子帧。 [0068] 在本发明实施例中，通过以下公式可以获取用户所处的寻呼时机：i_s＝floor(UE_ID/N)mod Ns；其中，i_s表示寻呼时机的索引号，NS表示1和Nb/T的较大值，Nb表示寻呼的密度，在本实施例中，Nb为4*T，表示每个无线帧中有4个子帧可用于寻呼，T为用户的不连续接收周期；UE_ID表示用户的标识；N表示1和Nb的较小值；floor(UE_ID/N)表示取小于UE_ID/N的最大整数值；在i_s为0，NS为4的情况下，寻呼时机为子帧0；在i_s为1，NS为4的情况下，寻呼时机为子帧4；在i_s为2，NS为4的情况下，寻呼时机为子帧5；在i_s为3，NS为4的情况下，寻呼时机为子帧9。 [0069] 在本发明实施例中，图2是根据本发明实施例的寻呼处理方法的流程图二，如图2所示，在步骤S104之后，上述方法还包括： [0070] 步骤S202，将寻呼时机相同的多个用户的寻呼内容合并成一条寻呼消息，将寻呼消息通过寻呼信道传输给多个用户。 [0071] 需要说明的是，上述寻呼消息中可以存在多个用户的寻呼内容，一般情况下，上述一条寻呼消息不超过16个用户的寻呼内容。 [0072] 在本实施例中还提供了一种寻呼处理方法，图3是根据本发明实施例的寻呼处理方法的流程图三，如图3所示，该流程包括如下步骤： [0073] 步骤S302，获取用户所处的寻呼时机； [0074] 步骤S304，在寻呼时机为子帧4和/或9的情况下，在子帧0和/或5上监听寻呼消息。 [0075] 通过上述步骤，采用在寻呼时机为子帧4和/或9的情况下，采用在子帧0和/或5上监听寻呼消息的方式，即通过修改子帧4和/或9，使得监听寻呼的任务由子帧0和/或5来承担，进而子帧4和/或9可以空余为普通子帧，实现将空余的子帧4和/或9配置为其他子帧，进而解决了FDD模式下，相关技术中的子帧配置无法满足传输技术中的特殊需求的问题，将更多的子帧配置成为满足特殊需求的特别子帧，提高了子帧资源利用率。 [0076] 需要说明的是，上述方法可以应用于FDD模式下。需要说明的是，上述特殊需求可以是增强视频的需求，也可以是增强音频的需求，但并不限于此。 [0077] 在一个可选的实施例中，上述子帧4和/或9可以作为多播组播单频网络MBSFN子帧进行使用，即可以将子帧4和/或9配置成为MBSFN子帧，以满足增强视频的需求，能够提高MBSFN子帧的配置率，进而提高了eMBMS的资源利用率。 [0078] 在本发明实施例中，上述步骤S304中的在寻呼时机为子帧4和/或9的情况下，在子帧0和/或5上监听寻呼消息可以通过以下方式实现：在i_s为1，NS为4的情况下，将i_s设置为0和/或2；和/或，在i_s为3，NS为4的情况下，将i_s设置为0和/或2；其中，i_s表示寻呼时机的索引号，NS表示1和Nb/T的较大值，Nb表示寻呼的密度，在本实施例中，Nb为4*T，表示每个无线帧中有4个子帧用于监听寻呼，T为用户的不连续接收周期；在i_s为0，NS为4的情况下，寻呼时机为子帧0；在i_s为1，NS为4的情况下，寻呼时机为子帧4；在i_s为2，NS为4的情况下，寻呼时机为子帧5；在i_s为3，NS为4的情况下，寻呼时机为子帧9；在NS为4以及设置后的i_s所指示的寻呼时机上监听寻呼消息。即通过修改设置寻呼时机的索引号i_s来达到修改寻呼子帧配置的目的，在通过该技术特征可以实现本该在子帧4监听寻呼的用户放在子帧0或子帧5来进行监听，本该在子帧9监听寻呼的用户放在子帧5或子帧0进行，将子帧4和/或9空余出来，进而能够将空余出的子帧 4和/或9配置成MBSFN子帧。 [0079] 在本发明实施例中，上述步骤S304中的在子帧0和/或5上监听寻呼消息可以包括：监听子帧0和/或5的物理下行控制信道PDCCH；根据PDCCH所指示的资源块RB分配方式和调制编码MCS方式，在寻呼时机的物理下行共享信道PDSCH上获取寻呼消息。 [0080] 在一个优选的实施例中，在一个寻呼周期内，用户仅在相应的一个寻呼位置监听寻呼消息，即在一个寻呼周期内，用户要么在子帧0上监听寻呼消息，要么在子帧5上监听寻呼消息。 [0081] 在本发明实施例中，图4是根据本发明实施例的寻呼处理方法的流程图四，如图4所示在步骤S304之后，上述方法还包括： [0082] 步骤S402，判断寻呼消息中是否含有用户的标识；如果是，则向用户所在的基站发送寻呼响应消息；如果否，则在预定时间后继续监听寻呼消息。 [0083] 上述用户的标识可以是上述实施例中的UE_ID，在一个优选的实施例中，用户还可以计算自己的标识，具体地，可以自身的IMSI或MME分配的S-TMSI计算出UE标识(UE ID)，即UE_ID:IMSI mod 1024。上述预定时间可以是间隔n个无线帧，其中，n为整数，也可以是其他时间，其可以按照实际情况进行设定的。 [0084] 需要说明的是，上述图1至图2所示的实施例可以通过基站来实现，图3至图4所示的实施例可以通过终端来实现，基站对用户进行寻呼的方法和终端监听寻呼的方法可以是对应的，即上述两个实施例可以结合，基站侧对子帧进行修改，终端也对该相应子帧做相应的修改，比如，基站确定所述寻呼时机为子帧4和/或9时，则基站采用子帧0和/或5来寻呼用户，那么终端同样在确定寻呼时机为4和/或9时，也采用子帧0和/或5来监听寻呼，即当基站采用子帧0寻呼用户时，终端也采用子帧0来进行监听寻呼，当基站采用子帧5寻呼用户时，终端也采用子帧5来进行监听寻呼。 [0085] 为了更好的理解本发明，以下结合优选的实施例对本发明做进一步的解释。 [0086] 由表1所示，paging子帧0,5出现在Ns＝4，i_s＝0和i_s＝2的时候。Ns＝Ns:max(1,nB/T)＝4，也即是nB/T＝4,那么在SIB2中关于nB的参数应设置为4T。由现有技术方案可知，N:min(T,nB)，即N＝1，而由上述公式得知i_s＝floor(UE_ID/N)mod Ns＝floor(UE_ID)mod 4，无线帧：SFN mod T＝(T div N)*(UE_ID mod N)＝(T)*(UE_ID)。 [0087] 本发明提供了一种优选的寻呼处理方法，图5是本发明优选实施例中的寻呼时机计算的流程示意图，如图5所示，在网络侧，若i_s＝floor(UE_ID/N)mod Ns＝floor(UE_ID)mod 4＝1，则将i_s设置为0(或者设置为2)；若i_s＝floor(UE_ID/N)mod Ns＝floor(UE_ID)mod 4＝3，则将i_s设置为2(或者设置为0)；即将本应该由子帧4寻呼的用户放到子帧0进行寻呼，将本应该由子帧9寻呼的用户放到子帧5进行寻呼。在UE侧，若i_s＝floor(UE_ID/N)mod Ns＝floor(UE_ID)mod 4＝1，则将i_s设置为0(或者设置为2)；若i_s＝floor(UE_ID/N)mod Ns＝floor(UE_ID)mod 4＝3，则将i_s设置为2(或者设置为0)；即将本应该在子帧4监听寻呼的用户放到子帧0进行监听，将本应该在子帧9监听寻呼的用户放到子帧5进行监听。 [0088] 以下结合具体的应用场景对本发明优选实施例组进一步的解释。 [0089] 场景一：足球比赛现场，实时直播，需要大量的网络资源进行数据传输。用户A呼叫空闲(idle)态的用户B，在该场景下，本优选实施例包括以下步骤： [0090] 本优选实施例包括基站侧的寻呼处理方法流程，还包括用户侧的寻呼处理方法的流程，其中，基站侧的寻呼处理方法流程包括步骤1至步骤2，用户侧的寻呼处理方法的流程包括步骤3至步骤6。 [0091] 图6示出了本优选实施例的寻呼处理方法的一个处理流程，该处理流程通过以下方式实现： [0092] 步骤1，基站配置寻呼控制信道(Paging Control Channel，简称PCCH)下的参数nB＝flour(T),T为UE的DRX寻呼周期(T可以为系统信息中广播小区默认的DRX寻呼周期，也可以是UE根据自身的电量与寻呼系统来设置的特定DRX寻呼周期)，参数T和nB这两个参数由系统消息SIB2通知UE； [0093] 步骤2，基站从MME处接收到寻呼(paging)信息，根据参数T，nB以及被寻呼的UE_ID(UE_ID是IMSI或者是MME分配的S-TMSI)计算出各个用户的寻呼时机(相当于图1所示的步骤S102)，若i_s＝floor(UE_ID/N)mod Ns＝floor(UE_ID)mod 4＝1，则将i_s设置为0；若i_s＝floor(UE_ID/N)mod Ns＝floor(UE_ID)mod 4＝3，则将i_s设置为2；即将本应该由子帧4寻呼的用户放到子帧0进行寻呼，将本应该由子帧9寻呼的用户放到子帧5进行寻呼(与图1所示实施例中的步骤S104中的“在确定寻呼时机为子帧4或9的情况下，采用子帧0和/或5寻呼用户”相同)。并将寻呼时机相同的UE的寻呼内容汇成一条寻呼消息(一条寻呼消息不超过16个用户)，通过寻呼信道传输给该寻呼时机的每个用户(相当于图2所示实施例中的步骤S202)。 [0094] 图7示出了本优选实施例的寻呼处理方法的一个处理流程，该处理流程通过以下方式实现： [0095] 步骤3，用户A通过自身的国际移动用户标识(IMSI，International Mobile Subscriber Identity) 或 MME 分 配 的 S-TMSI(SAE Temporary Mobile Station Identifier)计算出UE标识(UE ID)，即UE_ID:IMSI mod 1024； [0096] 步骤4，使用相同的寻呼周期计算该UE所处的寻呼时机(无线帧+子帧位置i_s)(相当于图3所述实施例中的步骤S302)，无线帧：SFN mod T＝(T div N)*(UE_ID mod N)＝(T)*(UE_ID)。若i_s＝floor(UE_ID/N)mod Ns＝floor(UE_ID)mod 4＝1，则将i_s设置为0；若i_s＝floor(UE_ID/N)mod Ns＝floor(UE_ID)mod 4＝3，则将i_s设置为2；即将本应该在子帧4监听寻呼的用户放到子帧0进行监听，将本应该在子帧9监听寻呼的用户放到子帧5进行监听(相当于图3所述实施例中步骤S304中的在寻呼时机为子帧 4或9的情况下，在子帧0和/或5上监听寻呼消息)。 [0097] 步骤5，在每一个寻呼周期内，UE仅在相应的一个寻呼位置监听寻呼信息。 [0098] 步骤6，用户A开始监听相应的寻呼子帧的PDCCH，并用P-RNTI去检测PDCCH，如果能解出，则用户A根据PDCCH指示的RB分配和调制编码方式(MCS)，从同一子帧的PDSCH上获取寻呼消息；如果寻呼消息含有本UE的ID，则发起寻呼响应；否则在间隔n个无线帧后继续监听相应子帧的PDCCH(相当于图4所示实施例中的步骤S402)，具体用户发起寻呼响应的流程可如图8所示。 [0099] 场景2：演唱会现场，实时直播，需要大量的网络资源进行数据传输，地震海啸预警(Earthquake and Tsunami Warning System，简称ETWS)，需要基站向其所辖用户发出预警信息，用户A接收此paging信息，假定此时paging信息中只有ETWS信息。在该场景下，本优选实施例包括以下步骤： [0100] 本优选实施例包括基站侧的寻呼处理方法流程，还包括用户侧的寻呼处理方法的流程，其中，基站侧的寻呼处理方法流程包括步骤1至步骤2，用户侧的寻呼处理方法的流程包括步骤3至步骤6。 [0101] 图9示出了本优选实施例的寻呼处理方法的一个处理流程，该处理流程通过以下方式实现： [0102] 步骤1，基站配置PCCH下的参数nB＝flour(T),T为UE的DRX寻呼周期(T可以为系统信息中广播小区默认的DRX寻呼周期，也可以是UE根据自身的电量与寻呼系统来设置的特定DRX寻呼周期)，参数T和nB这两个参数由系统消息SIB2通知UE。 [0103] 步骤2，基站在寻呼时机子帧0,5上发送ETWS信息，通过寻呼信道传输给该寻呼时机的每个用户(相当于图1所述实施例的步骤S104)。 [0104] 在本优选实施例中用户侧的寻呼处理方法与图7所述的寻呼处理方法的流程一致，包括： [0105] 步骤3，用户A通过自身的国际移动用户标识(IMSI，International Mobile Subscriber Identity) 或 MME 分 配 的 S-TMSI(SAE Temporary Mobile Station Identifier)计算出UE标识(UE ID)，即UE_ID:IMSI mod 1024。 [0106] 步骤4，使用相同的寻呼周期计算该UE所处的寻呼时机(无线帧+子帧位置i_s)相当于图3所述实施例中的步骤S302)，无线帧：SFN mod T＝(T div N)*(UE_ID mod N)＝(T)*(UE_ID)。若i_s＝floor(UE_ID/N)mod Ns＝floor(UE_ID)mod 4＝1，则将i_s设置为0；若i_s＝floor(UE_ID/N)mod Ns＝floor(UE_ID)mod 4＝3，则将i_s设置为2；即将本应该在子帧4监听寻呼的用户放到子帧0进行监听，将本应该在子帧9监听寻呼的用户放到子帧5进行监听(相当于图3所述实施例中步骤S304中的在寻呼时机为子帧 4或9的情况下，在子帧0和/或5上监听寻呼消息)。 [0107] 步骤5，在每一个寻呼周期内，UE仅在相应的一个寻呼位置监听寻呼信息。 [0108] 步骤6，用户开始监听相应的寻呼子帧的PDCCH，并用P-RNTI去检测PDCCH，如果能解出，则用户根据PDCCH指示的RB分配方式和调制编码方式(MCS)，从同一子帧的PDSCH上获取寻呼消息，否则在间隔n个无线帧后继续监听相应子帧的PDCCH(相当于图4所述实施例中的步骤S402)。如果寻呼信息中包含etws-Indication,触发UE立刻重选去获得SIB1信息，如果SIB1中scheduling Info List存在SIB10，SIB11，则UE立刻去获得SIB10，SIB11并读取ETWS预警信息，具体的用户获取ETWS信息的流程可如图10所示，。 [0109] 通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。 [0110] 在本实施例中还提供了一种寻呼处理装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。 [0111] 图11是根据本发明实施例的寻呼处理装置的结构框图一，如图11所示，该装置位于网络侧，用于频分双工FDD模式，包括： [0112] 获取模块1102，用于获取用户所处的寻呼时机； [0113] 寻呼模块1104，与上述获取模块1102连接，用于在确定寻呼时机为子帧4和/或9的情况下，采用子帧0和/或5寻呼用户。 [0114] 通过上述装置，寻呼模块1104在寻呼时机为子帧4和/或9的情况下，采用子帧0和/或5寻呼用户，即上述装置通过修改子帧4和/或9，使得寻呼的任务由子帧0和/或5来承担，进而将子帧4和/或9空余成普通子帧，进而可以将空余出的子帧4和/或9配置成其他子帧，进而解决了FDD模式下，相关技术中的子帧配置无法满足传输技术中的特殊需求的问题，将更多的子帧配置成为满足特殊需求的特别子帧，提高了子帧资源利用率。 [0115] 需要说明的是，上述特殊需求可以是增强视频的需求，也可以是增强音频的需求，但并不限于此。 [0116] 在一个可选的实施例中，上述子帧4和/或9可以作为多播组播单频网络MBSFN子帧使用，即上述装置可以将子帧4和/或9配置成为MBSFN子帧，以满足增强视频的需求，能够提高MBSFN子帧的配置率，进而提高了eMBMS的资源利用率。 [0117] 在本发明实施例中，图12是根据本发明实施例的寻呼处理装置的结构框图二，上述寻呼模块1104可以包括： [0118] 设置单元1202，用于在寻呼子帧图案中的i_s为1，NS为4的情况下，将i_s设置为0和/或2；和/或，在i_s为3，NS为4的情况下，将i_s设置为0和/或2；其中，i_s表示寻呼时机的索引号，NS表示1和Nb/T的较大值，Nb表示寻呼的密度，Nb为4*T，表示每个无线帧中有4个子帧可用于寻呼，T为用户的不连续接收周期；在i_s为0，NS为4的情况下，寻呼时机为子帧0；在i_s为1，NS为4的情况下，寻呼时机为子帧4；在i_s为2，NS为4的情况下，寻呼时机为子帧5；在i_s为3，NS为4的情况下，寻呼时机为子帧9； [0119] 寻呼单元1204，与上述设置单元1202连接，用于采用NS为4以及设置后的i_s所共同指示的寻呼时机寻呼用户。 [0120] 通过该设置单元1202修改寻呼时机的索引号i_s来完成修改寻呼子帧配置的目的，在配置完成之后，寻呼单元1204利用设置后的i_s所指示的寻呼时机寻呼用户，即采用子帧0或子帧5来进行寻呼，使得本该由子帧4寻呼的用户改由子帧0或子帧5来进行，本由子帧9寻呼的用户改由子帧5或子帧0进行，将子帧4和/或9空余出来，进而能够将空余出的子帧4和/或9配置成MBSFN子帧。 [0121] 在一个优选的实施例中，上述获取单元1102可以通过以下公式来获取用户所处的寻呼时机：i_s＝floor(UE_ID/N)mod Ns；其中，i_s表示寻呼时机的索引号，NS表示1和Nb/T的较大值，Nb表示寻呼的密度，Nb为4*T，表示每个无线帧中有4个子帧可用于寻呼，T为用户的不连续接收周期；UE_ID表示用户的标识；N表示1和Nb的较小值；floor(UE_ID/N)表示取小于UE_ID/N的最大整数值；在i_s为0，NS为4的情况下，寻呼时机为子帧0；在i_s为1，NS为4的情况下，寻呼时机为子帧4；在i_s为2，NS为4的情况下，寻呼时机为子帧5；在i_s为3，NS为4的情况下，寻呼时机为子帧9。 [0122] 在本发明实施例中，图13是根据本发明实施例的寻呼处理装置的结构框图三，如图13所示，上述装置还包括： [0123] 传输模块1302，与上述寻呼模块1104连接，用于将寻呼时机相同的多个用户的寻呼内容合并成一条寻呼消息，将寻呼消息通过寻呼信道传输给多个用户。 [0124] 需要说明的是，上述寻呼消息中可以存在多个用户的寻呼内容，一般情况下，上述一条寻呼消息不超过16个用户的寻呼内容。 [0125] 在本实施例中还提供了一种寻呼处理装置，图14是根据本发明实施例的寻呼处理装置的结构框图四，如图14所示，该装置位于终端中，用于频分双工FDD模式，包括： [0126] 获取模块1402，用于获取用户所处的寻呼时机； [0127] 监听模块1404，与上述获取模块1402连接，用于在寻呼时机为子帧4和/或9的情况下，在子帧0和/或5上监听寻呼消息。 [0128] 通过上述装置，监听模块1404采用在寻呼时机为子帧4和/或9的情况下，采用在子帧0和/或5上监听寻呼消息的方式，即通过上述装置使得监听寻呼的任务都由子帧0和/或5来承担，子帧4和/或9空余成普通子帧，进而使得子帧4和/或9可作为其他子帧使用，进而解决了FDD模式下，相关技术中的子帧配置无法满足传输技术中的特殊需求的问题，将更多的子帧配置成为满足特殊需求的特别子帧，提高了子帧资源利用率。 [0129] 需要说明的是，上述特殊需求可以是增强视频的需求，也可以是增强音频的需求，但并不限于此。 [0130] 在一个可选的实施例中，上述子帧4和/或9可以作为多播组播单频网络MBSFN子帧进行使用，即可以将子帧4和/或9配置成为MBSFN子帧，以满足增强视频的需求，能够提高MBSFN子帧的配置率，进而提高了eMBMS的资源利用率。 [0131] 在本发明实施例中，图15是根据本发明实施例的寻呼处理装置的结构框图五，如图15所示，上述监听模块1404可以包括： [0132] 设置单元1502，用于在i_s为1，NS为4的情况下，将i_s设置为0和/或2；和/或，在i_s为3，NS为4的情况下，将i_s设置为0和/或2；其中，i_s表示寻呼时机的索引号，NS表示1和Nb/T的较大值，Nb表示寻呼的密度，Nb为4*T，表示每个无线帧中有4个子帧用于监听寻呼，T为用户的不连续接收周期；在i_s为0，NS为4的情况下，寻呼时机为子帧0；在i_s为1，NS为4的情况下，寻呼时机为子帧4；在i_s为2，NS为4的情况下，寻呼时机为子帧5；在i_s为3，NS为4的情况下，寻呼时机为子帧9； [0133] 第一监听单元1504，与上述设置单元1502连接，用于在NS为4以及设置后的i_s所共同指示的寻呼时机上监听寻呼消息。 [0134] 上述设置单元1502通过修改设置寻呼时机的索引号i_s来达到修改寻呼子帧配置的目的，第一监听单元1505在上述设置单元1502设置完成之后，利用设置后的i_s所指示的寻呼时机来监听寻呼消息，即通过上述装置，使得本该在子帧4监听寻呼的用户放在子帧0或子帧5来进行监听，本该在子帧9监听寻呼的用户放在子帧5或子帧0进行，将子帧4和/或9空余出来，进而能够将空余出的子帧4和/或9配置成MBSFN子帧。 [0135] 在本发明实施例中，上述监听模块1404还可以包括：第二监听单元，用于监听子帧0和/或5的物理下行控制信道PDCCH；获取单元，与上述第二监听单元连接，用于根据PDCCH所指示的资源块RB分配方式和调制编码MCS方式，在寻呼时机的物理下行共享信道PDSCH上获取寻呼消息。 [0136] 在一个优选的实施例中，在一个寻呼周期内，用户仅在相应的一个寻呼位置监听寻呼消息，即在一个寻呼周期内，用户要么在子帧0上监听寻呼消息，要么在子帧5上监听寻呼消息。 [0137] 在本发明实施例中，图16是根据本发明实施例的寻呼处理装置的结构框图六，如图16所示，上述装置还包括：判断模块1602，用于判断寻呼消息中是否含有用户的标识；发送模块1604，与上述判断模块1602连接，用于在是的情况下，向用户所在的基站发送寻呼响应消息； [0138] 上述监听模块1404，与上述判断模块1602连接，还用于在否的情况下，在预定时间后继续监听寻呼消息。 [0139] 上述用户的标识可以是上述实施例中的UE_ID，在一个优选的实施例中，上述装置还可以计算该装置所在的终端的用户标识，具体地，可以自身的IMSI或MME分配的S-TMSI计算出UE标识(UE ID)，即UE_ID:IMSI mod 1024。上述预定时间可以是间隔n个无线帧，其中，n为整数，也可以是其他时间，其可以按照实际情况进行设定的。 [0140] 在该实施例中的寻呼处理装置都可以应用于上述的图5至图10所述的优选实施例中，其中，上述基站侧的寻呼处理装置可以实现图5至图10所述的优选实施例中基站所完成的功能，终端侧的寻呼处理装置可以实现图5至图10所述的优选实施例中用户侧(终端)所完成的功能，此处不再赘述。 [0141] 本发明实施例还提供了一种系统，包括基站和终端；其中，该基站中包括上述图11至图13所示的实施例中的寻呼处理装置，终端包括上述图14至图16所示的寻呼处理装置；该寻呼处理装置完成的功能与该寻呼监听装置完成的功能是对应的，即基站侧对子帧进行修改，终端也对该相应子帧做相应的修改，比如，寻呼模块1104确定所述寻呼时机为子帧4和/或9时，则采用子帧0和/或5来寻呼用户，那么监听模块1404，在确定寻呼时机为4和/或9时，也采用子帧0和/或5来监听寻呼，即当基站采用子帧0寻呼用户时，终端也采用子帧0来进行监听寻呼，当基站采用子帧5寻呼用户时，终端也采用子帧5来进行监听寻呼。 [0142] 需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述模块分别位于多个处理器中。 [0143] 本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以被设置为存储用于执行图1至图4所示实施例中的步骤的程序代码，具体详见图1至图4所示实施例，此处不再赘述。 [0144] 可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。 [0145] 可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。 [0146] 显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。 [0147] 以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。 |
||||||
QQ群二维码
意见反馈
意见反馈