组寻呼区域信息的通知方法和设备 |
|||||||
| 申请号 | CN201110242935.7 | 申请日 | 2011-08-23 | 公开(公告)号 | CN102291824A | 公开(公告)日 | 2011-12-21 |
| 申请人 | 电信科学技术研究院; | 发明人 | 张惠英; 张英; | ||||
| 摘要 | 本 发明 实施例 公开了一种组寻呼区域信息的通知方法和设备，通过应用本发明实施例的技术方案，RAN侧可以通过MTCServer提供的组寻呼区域信息以及小区 覆盖 信息，进一步细化组寻呼区域的范围，从而，在基于组管理用户的情况下，能够更准确的确定寻呼范围，提高组寻呼效率，避免组寻呼过程中寻呼范围过大造成的资源浪费，通过这样的处理，避免了 现有技术 中大量用户接收到组寻呼而发起随机接入对RAN负荷造成冲击，以及对传统的H2H用户造成影响。 | ||||||
| 权利要求 | 1.一种组寻呼区域信息的通知方法，其特征在于，至少包括以下步骤： RAN设备接收到MTC Sever发送的控制面消息，所述控制面消息中携带组寻呼区域信息； |
||||||
| 说明书全文 | 组寻呼区域信息的通知方法和设备技术领域[0001] 本发明涉及通信技术领域，特别涉及一种组寻呼区域信息的通知方法和设备。 背景技术[0002] 机器类型通信（Machine-Type Communication，MTC）作为一种新型的通信理念，其目的是将多种不同类型的通信技术有机结合，如：机器对机器通信、机器控制通信、人机交互通信、移动互联通信，从而推动社会生产和生活方式的发展。预计未来人对人通信的业务可能仅占整个终端市场的1/3，而更大数量的通信是MTC通信业务。有时，MTC通信又称为机器间（Machine-To-Machine，M2M）通信或物联网。 [0003] 当前的移动通信网络是针对人与人（Human to Human，H2H）之间的通信设计的，如：网络容量的确定等。如果希望利用移动通信网络来支持MTC通信就需要根据MTC通信的特点对移动通信系统的机制进行优化，以便能够在对传统的人与人通信不受或受较小影响的情况下，更好地实现MTC通信。 [0004] 当前认识到的MTC通信可能存在的一些特点有：MTC设备具有低移动性； MTC设备与网络侧进行数据传输的时间是可控的； MTC网络与网络侧进行的数据传输对数据传输对实时性要求不高，即：具有时间容忍性； MTC设备能量受限，要求极低的功率消耗； MTC设备和网络侧之间只进行小数据量的信息传输； MTC设备可以以组为单位进行管理； …… 一个实际的MTC设备可以具有上述的一个或多个特点。 [0005] 对大量M2M用户的通信进行管理的情况下，一种可以提升管理效率的方法是对具有某种或某些相同业务特性的用户将其规划为一组，以组的单位进行管理。比如，对一组用户，需要通知其进行数据上报。目前在3GPP（Third Generation Partnership Project，第三代移动通信伙伴计划）范畴讨论的一种可能方式是MTC server（服务器）通知核心网向该组用户发起寻呼（paging），RAN（Radio Access Network，无线接入网）将寻呼信息发送到空口，属于该群组的M2M用户接收到寻呼信息后即发起随机接入过程，与网络建立通信链路后，发送所要求的数据。 [0006] 目前所讨论的基于组为单位进行用户数据上报管理的方法，为了避免某个组的大量用户在接收到组寻呼后集中发起随机接入导致网络发生拥塞，系统可以通过一定的接入时间随机化解决该问题；也可以通过为这部分M2M用户分配专用的PRACH（PhysicalRandom Access Channel，物理随机接入信道）资源来减少对H2H用户接入的影响。 [0007] 对于UMTS（Universal Mobile Telecommunications System，通用移动通信系统）系统，核心网通过Iu接口（Iu接口负责核心网和RNC之间的信令交互）控制面RANAP（Radio Access Network Application Part，无线接入网络应用部分）消息，发送paging消息给RNC（Radio Network Controller，无线网络控制器），paging范围为LA（Location Area，位置区域）/RA（Routing Area，路由区域）。对于LTE（Long Term Evolved，长期演进）系统，核心网通过S1接口（S1接口提供无线与核心网络连接）控制面S1AP（Application Part，应用协议）消息，发送paging消息给eNB（evolved Node B，演进的B节点，即基站），paging范围为TA（Tracking Area，跟踪区域）。 [0008] 在实现本发明的过程中，发明人发现现有技术中至少存在以下问题：根据现有技术的介绍可知，目前的寻呼是基于LA/RA（UMTS）或TA（LTE）的，而在M2M基于组的技术方案讨论中，组寻呼是一种有效的方案，但是目前的寻呼机制限制了寻呼范围为LA/RA（UMTS）或TA（LTE），而MTC server希望获取数据的范围并不与LA/RA（UMTS）或TA（LTE）重合，这样就降低了组寻呼的效率，并可能造成不必要的资源浪费。 发明内容[0009] 本发明实施例提供一种组寻呼区域信息的通知方法和设备，解决现有的技术方案中基于组用户管理的情况下，不能准确的确定寻呼范围的问题。 [0010] 为达到上述目的，本发明实施例一方面提供了一种组寻呼区域信息的通知方法，至少包括以下步骤：RAN设备接收到MTC Sever发送的控制面消息，所述控制面消息中携带组寻呼区域信息； 所述RAN设备根据所述组寻呼区域信息，确定发起组寻呼的寻呼区域。 [0011] 另一方面，本发明实施例还提供了一种RAN设备，至少包括：接收模块，用于接收MTC Sever发送的控制面消息，所述控制面消息中携带组寻呼区域信息； 处理模块，用于根据所述接收模块所接收到的组寻呼区域信息，确定发起组寻呼的寻呼区域。 [0012] 另一方面，本发明实施例还提供了一种组寻呼区域信息的通知方法，至少包括以下步骤：MTC Sever向RAN设备发送携带组寻呼区域信息的控制面消息，以使所述RAN设备根据所述组寻呼区域信息确定发起组寻呼的寻呼区域。 [0013] 另一方面，本发明实施例还提供了一种MTC Server，至少包括： 发送模块，用于向RAN设备发送携带组寻呼区域信息的控制面消息，以使所述RAN设备根据所述组寻呼区域信息确定发起组寻呼的寻呼区域。 [0014] 与现有技术相比，本发明实施例所提出的技术方案具有以下优点：通过应用本发明实施例的技术方案，RAN侧可以通过MTC Server提供的寻呼区域信息以及小区覆盖信息，进一步细化组寻呼区域的范围，从而，在基于组管理用户的情况下，能够更准确的确定寻呼范围，提高组寻呼效率，避免组寻呼过程中寻呼范围过大造成的资源浪费，通过这样的处理，避免了现有技术中大量用户接收到组寻呼而发起随机接入对RAN负荷造成冲击，以及对传统的H2H用户造成影响。 附图说明 [0015] 图1为本发明实施例所提出的一种组寻呼区域信息的通知方法的流程示意图；图2为本发明实施例所提出的一种UMTS的应用场景中的组寻呼区域信息的通知方法的流程示意图； 图3为本发明实施例所提出的一种LTE系统的应用场景中的组寻呼区域信息的通知方法的流程示意图； 图4为本发明实施例提出的一种RAN设备的结构示意图； 图5为本发明实施例提出的一种MTC Server的结构示意图。 具体实施方式[0016] 如背景技术所述，机器到机器通信是未来智能化发展的一种趋势。在第三代移动通信系统以及其长期演进系统中需要支持MTC功能。而当前的通信系统网络是对人与人之间的通信设计的，如系统容量、过载控制机制等。在大量的M2M通信应用场景中，MTC功能的终端数量将远远大于H2H的普通终端，可能达到现有移动终端数量的几十倍。那么，在某些应用场景下（例如具有相同业务需求的metering等），可以考虑对M2M用户进行分组管理，当MTC server需要针对某一组M2M用户进行相同的处理，通过寻呼一组M2M用户，要求M2M用户上报数据，但是目前的寻呼机制限制了寻呼范围为LA/RA（UMTS）或TA（LTE），而MTC server希望获取数据的范围并不与LA/RA（UMTS）或TA（LTE）重合，可能远小于LA/RA（UMTS）或TA（LTE）的范围，这样就降低了组寻呼的效率，并可能造成不必要的资源浪费。 [0018] 如图1所示，为本发明实施例所提出的一种组寻呼区域信息的通知方法的流程示意图，该方法具体包括以下步骤：步骤S101、RAN设备接收到MTC Sever发送的控制面消息，该控制面消息中携带组寻呼区域信息。 [0019] 在具体的实施场景中，本步骤中的控制面消息的传输过程实际是通过核心网进行转发来完成的，具体的，本步骤中的操作过程实际为RAN设备通过核心网设备接收到MTC Sever发送的控制面消息。 [0020] 在实际应用中，基于系统类型的差异，RAN设备的物理实体，以及在核心网中的具体传输过程均会存在相应的区别，具体说明如下：（1）UMTS系统。 [0021] 本步骤中的RAN设备实际为RNC，相应的处理过程为RNC通过Iu接口接收核心网设备所转发的MTC Sever发送的控制面消息。 [0022] 进一步的，此种情况下，MTC Sever发送的控制面消息，具体为控制面RANAP协议的寻呼消息。 [0023] （2）LTE系统。 [0024] 本步骤中的RAN设备实际为eNB，相应的处理过程为eNB通过S1接口接收核心网设备所转发的MTC Sever发送的控制面消息。 [0025] 进一步的，此种情况下，MTC Sever发送的控制面消息，具体为控制面S1 AP协议的寻呼消息。 [0026] 为了准确的传输相应的寻呼范围的信息，上述的MTC Sever发送的控制面消息中所携带的组寻呼区域信息具体包括以下两方面的内容。 [0027] A、进行组寻呼的组标识信息。 [0028] B、进行组寻呼的区域信息。 [0029] 其中，在具体的实施场景中，进行组寻呼的区域信息具体可以为以下类型的信息的任意一种：以指定位置为中心，具有预设长度的半径的圆形区域的信息；或， 以指定位置为中心，具有预设长度的半径的扇形区域的信息；或， 以指定位置为方位点，具有预设长度的长和宽的矩形区域的信息；或， 区域映射表中所包括的具体区域的编号信息。 [0030] 当然，在实际的应用场景中，如果能够达到相应的寻呼范围确定效果，也可以采用其他类型的信息，这样的变化并不影响本发明的保护范围。 [0031] 步骤S102、RAN设备根据组寻呼区域信息，确定发起组寻呼的寻呼区域。 [0032] 同样的，在实际应用中，基于系统类型的差异，本步骤的处理过程也会存在相应的区别，具体说明如下：（1）UMTS系统。 [0033] 本步骤中的RAN设备实际为RNC，相应的处理过程为：RNC根据组寻呼信息和小区分布，确定发送组寻呼的小区； RNC通过Iub接口（Iub接口是RNC和eNB之间的接口，用来传输RNC和eNB之间的信令以及来自无线接口的数据）通知相应的基站对小区发起组寻呼。 [0034] （2）LTE系统。 [0035] 本步骤中的RAN设备实际为eNB，相应的处理过程为eNB根据组寻呼信息和小区分布，确定发送组寻呼的小区，并对小区发起组寻呼。 [0036] 基于以上的说明，具体的系统类型变化并不会影响本发明的保护范围，同时，如果有其他类型的系统可以实现相应的MTC Server对RAN设备的携带组寻呼区域信息的控制面消息的传输过程，同样可以应用本发明实施例所提出的技术方案，这样的变化并不影响本发明的保护范围。 [0037] 相对应的，在MTC Server侧，则是向RAN设备发送携带组寻呼区域信息的控制面消息的处理过程，具体的发送方式以及组寻呼区域信息的携带方式参见上述说明，与之相类似，在此，不再重复说明。 [0038] 与现有技术相比，本发明实施例所提出的技术方案具有以下优点：通过应用本发明实施例的技术方案，RAN侧可以通过MTC Server提供的寻呼区域信息以及小区覆盖信息，进一步细化组寻呼区域的范围，从而，在基于组管理用户的情况下，能够更准确的确定寻呼范围，提高组寻呼效率，避免组寻呼过程中寻呼范围过大造成的资源浪费，通过这样的处理，避免了现有技术中大量用户接收到组寻呼而发起随机接入对RAN负荷造成冲击，以及对传统的H2H用户造成影响。 [0039] 下面，结合具体的应用场景，对本发明实施例所提出的技术方案进行说明。 [0040] 结合前文所述的现有相关方案存在的问题，本发明实施例针对基于组管理，尤其是组寻呼过程中，RAN侧的设备如何有效进行寻呼小区的确定提出解决方案。 [0041] 本发明实施例所提出的技术方案的中心思想如下：MTC Server将组寻呼区域信息通过核心网通知给RAN设备，RAN设备根据相应的信息确定在哪个或哪几个小区发起寻呼。具体的，相应的寻呼区域信息可以是但不限于以下方面： （1）以某一位置（可以但不限于使用经纬度）为中心，半径固定的圆。 [0042] （2）以某一位置（可以但不限于使用经纬度）为中心，半径固定的扇形。 [0043] （3）以某一位置（可以但不限于使用经纬度）为方位点，长宽固定的矩形等。 [0044] （4）区域映射表中具体区域的编号等。 [0045] RAN根据寻呼区域信息和小区覆盖情况，确定具体发起寻呼的小区。 [0046] 以下针对UMTS系统和LTE系统分别给出相应的实施例。 [0047] 如图2所示，为本发明实施例所提出的一种UMTS的应用场景中的组寻呼区域信息的通知方法的流程示意图，该方案的具体步骤如下：步骤S201、MTC Server向核心网传输携带组寻呼相关信息的paging消息。 [0048] 步骤S202、核心网可以通过Iu接口控制面RANAP协议的PAGING消息将组寻呼相关信息通知RNC。 [0049] 其中，组寻呼区域信息可以是但不限于绝对地理位置区域信息，区域映射表中的索引等。 [0051] 表1 修改后的RANAP协议的PAGING消息的组成结构示意表其中，上述的带下划线的部分为paging消息中携带组寻呼区域信息的具体方式，当然，凡是可以达到同样技术效果的信元部署方式均可以应用于本技术方案，具体的信元名称和部署方式的变化并不影响本发明的保护范围。 [0052] 步骤S203、RNC接收到上述信息后，根据组寻呼区域信息和小区分布，确定发送组寻呼的小区，RNC通过Iub接口通知相应的基站设备。 [0053] 步骤S204、基站设备向相应的小区发起寻呼过程。 [0054] 如图3所示，为本发明实施例所提出的一种LTE系统的应用场景中的组寻呼区域信息的通知方法的流程示意图，该方案的具体步骤如下：步骤S301、MTC Server向核心网传输携带组寻呼相关信息的paging消息。 [0055] 步骤S302、核心网可以通过S1接口控制面S1AP协议的PAGING消息将组寻呼相关信息通知eNB。 [0056] 其中，组寻呼区域信息可以是但不限于绝对地理位置区域信息，区域映射表中的索引等。 [0057] 对现有S1AP协议的PAGING消息的一种可能的修改方式如表2所示。 [0058] 表2 修改后的S1AP协议的PAGING消息的组成结构示意表其中，上述的带下划线的部分为paging消息中携带组寻呼区域信息的具体方式，当然，凡是可以达到同样技术效果的信元部署方式均可以应用于本技术方案，具体的信元名称和部署方式的变化并不影响本发明的保护范围。 [0059] 步骤S303、eNB接收到上述信息后，根据组寻呼区域信息和小区分布，确定发送组寻呼的小区，发起寻呼过程。 [0060] 与现有技术相比，本发明实施例所提出的技术方案具有以下优点：通过应用本发明实施例的技术方案，RAN侧可以通过MTC Server提供的寻呼区域信息以及小区覆盖信息，进一步细化组寻呼区域的范围，从而，在基于组管理用户的情况下，能够更准确的确定寻呼范围，提高组寻呼效率，避免组寻呼过程中寻呼范围过大造成的资源浪费，通过这样的处理，避免了现有技术中大量用户接收到组寻呼而发起随机接入对RAN负荷造成冲击，以及对传统的H2H用户造成影响。 [0061] 为了实现本发明实施例的技术方案，本发明实施例还提供了一种RAN设备，其结构示意图如图4所示，至少包括：接收模块41，用于接收MTC Sever发送的控制面消息，控制面消息中携带组寻呼区域信息； 处理模块42，用于根据接收模块41所接收到的组寻呼区域信息，确定发起组寻呼的寻呼区域。 [0062] 其中，接收模块41，具体用于通过核心网设备接收到MTC Sever发送的控制面消息。 [0063] 具体的，在实际应用中，基于系统类型的差异，RAN设备的物理实体，以及接收模块41所接收到的信息在核心网中的具体传输过程均会存在相应的区别，具体说明如下： 在UMTS中，RAN设备具体为RNC，接收模块41，具体用于通过Iu接口接收核心网设备所转发的MTC Sever发送的控制面消息。 [0064] 在LTE系统中，RAN设备具体为eNB，接收模块41，具体用于通过S1接口接收核心网设备所转发的MTC Sever发送的控制面消息。 [0065] 需要指出的是，MTC Sever发送的控制面消息中所携带的组寻呼区域信息，具体包括进行组寻呼的组标识信息和进行组寻呼的区域信息；其中，进行组寻呼的区域信息，具体为： 以指定位置为中心，具有预设长度的半径的圆形区域的信息；或， 以指定位置为中心，具有预设长度的半径的扇形区域的信息；或， 以指定位置为方位点，具有预设长度的长和宽的矩形区域的信息；或， 区域映射表中所包括的具体区域的编号信息。 [0066] 同样的，在实际应用中，基于系统类型的差异，处理模块42的处理过程也会存在相应的区别，具体说明如下：在UMTS中，RAN设备具体为RNC，处理模块42，具体用于根据组寻呼信息和小区分布，确定发送组寻呼的小区。 [0067] 在LTE系统中，RAN设备具体为eNB，处理模块42，具体用于根据组寻呼信息和小区分布，确定发送组寻呼的小区，并对小区发起组寻呼。 [0068] 另一方面，本发明实施例还提供了一种MTC Server，其结构示意图如图5所示，至少包括：发送模块51，用于向RAN设备发送携带组寻呼区域信息的控制面消息，以使RAN设备根据组寻呼区域信息确定发起组寻呼的寻呼区域。 [0069] 其中，发送模块51，具体用于通过核心网设备向RAN设备发送携带组寻呼区域信息的控制面消息。 [0070] 具体的，在实际应用中，基于系统类型的差异，RAN设备的物理实体，以及发送模块51所发送的信息在核心网中的具体传输过程均会存在相应的区别，具体说明如下： 在UMTS中，发送模块51，具体用于通过核心网设备，由Iu接口向RNC发送携带组寻呼区域信息的控制面消息； 在LTE系统中，发送模块51，具体用于通过核心网设备，由S1接口向eNB发送携带组寻呼区域信息的控制面消息。 [0071] 需要指出的是，MTC Sever发送的控制面消息中所携带的组寻呼区域信息，具体包括进行组寻呼的组标识信息和进行组寻呼的区域信息；其中，进行组寻呼的区域信息，具体为： 以指定位置为中心，具有预设长度的半径的圆形区域的信息；或， 以指定位置为中心，具有预设长度的半径的扇形区域的信息；或， 以指定位置为方位点，具有预设长度的长和宽的矩形区域的信息；或， 区域映射表中所包括的具体区域的编号信息。 [0072] 与现有技术相比，本发明实施例所提出的技术方案具有以下优点：通过应用本发明实施例的技术方案，RAN侧可以通过MTC Server提供的寻呼区域信息以及小区覆盖信息，进一步细化组寻呼区域的范围，从而，在基于组管理用户的情况下，能够更准确的确定寻呼范围，提高组寻呼效率，避免组寻呼过程中寻呼范围过大造成的资源浪费，通过这样的处理，避免了现有技术中大量用户接收到组寻呼而发起随机接入对RAN负荷造成冲击，以及对传统的H2H用户造成影响。 [0073] 通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明实施例可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，本发明实施例的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质（可以是CD-ROM，U盘，移动硬盘等）中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或网络侧设备等）执行本发明实施例各个实施场景所述的方法。 [0074] 本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本发明实施例所必须的。 [0075] 本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。 [0076] 上述本发明实施例序号仅仅为了描述，不代表实施场景的优劣。 [0077] 以上公开的仅为本发明实施例的几个具体实施场景，但是，本发明实施例并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明实施例的业务限制范围。 |
||||||
