移动远程通信中的信号发送的制作方法

文档序号:7679424阅读:131来源:国知局
专利名称:移动远程通信中的信号发送的制作方法
技术领域
本发明涉及移动远程通信(mobile telecommunication)网络,具体地
但不是排他地涉及使用3GPP标准及其等价物和衍生物的移动远程通信网 络。
本申请基于并主张于2006年10月4日递交的英国专利申请 No.0619614.1的优先权,该英国专利申请的全部公开内容通过引用被结合 于此。
背景技术
移动远程通信网络中,小区需要将小区的系统参数发送给小区中的用 户设备(UE)。这要求基站定期的广播并占用一部分否则可用于通信的可 用无线电频谱/带宽。通常,大约百分之五的基站功率被用于在通信总体方 案中很重要的广播信道传输。

发明内容
WO02/056616A提出了在GPRS系统中, 一些系统信息仅应请求被直 接发送到提出请求的移动设备(以及共享同一 GPRS时隙的其它活动 (active)移动设备)。这存在如下的缺点只有活动UE能请求并接收所 请求的系统信息,并且仅部分的活动UE能接收到所请求的系统信息。
根据第一方面,提供了一种传送移动远程通信系统基站中的系统信息 的方法,该方法包括维护主系统信息;维护辅系统信息;定时地 (periodically)广播主系统信息;响应于触发事件,广播辅系统信息。
通过这种方法,仅相对少量的系统信息(即主系统信息)通常以定期 的、相对频繁的时间间隔被例行地广播。另外,仅响应于触发事件而广播 辅系统信息。因为经由广播信道而不是专用或共享信道来广播(即发送)辅系统信息,所以该辅系统信息可以被除请求设备以外的设备接收到,例
如,空闲模式(idle mode)下的设备可以被"被动地"更新而无需自己请 求信息。
触发事件可以包括从用户设备(UE)接收到对辅系统信息请求,该请 求指示需要辅助信息。另外,该请求可指示所需要的系统信息的组或类 型,例如用于呼叫建立的系统信息。
优选地基于小区资源,响应于触发事件,辅系统信息的广播优选地被 调度(schedule)用于(紧随其后的)广播;这使信息能够被有效地发 送。辅系统信息的内容可基于UE请求系统信息的原因。如果不同的UE 同时请求不同类型的系统信息,则可以广播所有的系统信息。
主系统信息优选地包括标识辅系统信息的下一次广播的调度信息,或 可获得标识辅系统信息的下一次广播的调度信息的位置。
调度信息可以包括时间和信道信息。
在一个实施例中,在没有触发事件的情况下,辅系统信息的广播不被 调度。在可替代的实施例中,辅系统信息以相对长的时间间隔被调度,优 选地以包括至少5个主系统信息广播的时间间隔被调度。这可以通过以下 方式来实现通过使用触发机制并响应于超时或主广播计数来生成触发事 件,或通过独立于触发机制、定时地调度附加的广播。在一个实施例中, 存在辅系统信息传输间的最小时间间隔。例如,如果该最小时间间隔是五 个主传输,则在响应于触发而发送辅系统信息后,网络将等待该时间间隔 然后重新开始定时的辅系统信息传输。
优选地,主系统信息以定期的时间间隔被发送。
主系统信息通常包括小区的标识符和一组小区无线电参数。
辅系统信息可以包括相邻小区信息。
信道或码序列(例如,RACH码序列)可以被保留用于从用户设备对 辅系统信息进行请求,并且其中对于从多于一个的用户设备接收到交叠的 (overlapping)请求,生成单个触发事件。
在第二方面中,本发明提供一种由移动远程通信系统的用户设备来获 得系统信息的方法,该方法包括接收由小区广播的主系统信息;
从主系统信息确定标识辅系统信息的广播的调度信息;
基于所接收的调度信息来接收辅系统信息。
该方法可以包括在没有经调度的或已接收到的辅系统信息的情况下, 在空闲模式下等待辅系统信息的调度。
该方法可以包括,在变换到活动模式后,在没有已接收到的辅系统信 息或调度信息的情况下,对辅系统信息进行请求。
请求可以包括使用所保留的信道或码序列来请求辅系统信息。
该方法可以包括在接收到所广播的主系统信息或辅系统信息后,对所 存储的系统信息进行更新。
该方法可以包括基于所接收到的主系统信息来预占小区而不请求或接 收辅系统信息。
第三方面提供了一种包括无线电接口和传输调度器的基站,所述无线 电接口和传输调度器被配置为执行根据第一方面或任何优选特征的方法。
第四方面提供了一种包括无线电接口和小区系统信息存储器的用户设 备,所述无线电接口和小区系统信息存储器被配置为执行根据第二方面或 任何优选特征的方法。
本发明还提供了一种包括指令的计算机程序或计算机程序产品或计算 机可读介质,所述指令在被移动远程通信系统的处理组件执行时使所述系 统执行根据方法的任一方面的方法。


图1示出传统的系统信息的定时广播。
图2示出根据第一实施例的系统信息的广播,在第一实施例中仅按需 发送辅系统信息。
图3示出根据第二实施例的系统信息的广播,在第二实施例中按需发 送辅系统信息并且附加地以经延长的时间间隔来发送辅系统信息。 图4示出所提出的第一信号发送序列。 图5示出所提出的第二信号发送序列。图6用图表示出有效的小区资源节省。
图7示出典型实施例中的定时关系。
图8示意性地示出可应用实施例的一种移动远程通信系统。
图9示意性地示出形成图8所示系统的一部分的基站。
图IO示意性地示出形成图8所示系统的一部分的移动通信设备。
具体实施例方式
现将参照附图描述示例性实施例。
LIE BCH设计的主要目的之一是优化对可用资源的使用。这意味着LIE BCH设计必须尽可能地设法减少BCH所需要的资源并设法消除由网络所传输的信息的重复。在戛纳(Cannes)的联合RAN1-RAN2会议中,讨论了发送BCH的单位比特成本。结论是BCH传输成本在瞬时功率消耗方面可能很高。我们提出了一种方法来帮助降低这种功率消耗。本文提出按需BCH (BCH-on-demand)的概念,其是针对辅BCH (S-BCH)传输的加强。本方案中,S-BCH以下面两种方式被发送*以很大的时间间隔定时地发送,以及
*当有对S-BCH的需求时发送。该需求以RACH的形式被指示,所述
RACH是由需要S-BCH信息的UE发送的。
l.按需BCH机制
在UMTS中,BCH的主要缺点是无论UE是否需要信息,BCH都被发送。通常,5。/。的基站功率被用于BCH传输,这是很大的比例。
不同于必须被频繁地发送以使UE能够有效地执行小区搜索过程的主BCH (P-BCH) , S-BCH可以不必被定期地发送(在小区内没有UE的情况下或者在没有UE想要迫切地读取S-BCH的情况下)。因此,为了进一步减少BCH的瞬时功率需求并优化对网络资源的使用,提出了使定时S-BCH具备很长的时间间隔。
另外,为了帮助縮短获得S-BCH的延迟,提出了还具备"按需S-BCH"。定时S-BCH的内容和按需S-BCH的内容一般是相同的。但是,按需S-BCH的内容可以根据请求它的UE的意图被定制,例如,想要按需
7S-BCH以进行呼叫的UE可以发送系统信息的有关部分。
尽管本提议主要是使空闲UE能够请求待发送的S-BCH,但是这并不排除使所连接的UE能够例如经由L2或L3信号发送来请求待调度的S-BCH。图1到图3示出传统的辅系统信息的信号发送,按需的辅系统信息的信号发送,以及按需加经延长时间间隔的辅系统信息的信号发送。
对于按需S-BCH, UE可通过发送RACH前导(preamble)(例如通过特定的原因值或特定的随机ID),来指示其需要S-BCH。
在下面的部分,我们讨论不同的情境,其中UE将需要S-BCH。这些情境是
*例1: UE具有存储在存储器中的S-BCH并想要连接到网络;
*例2: UE不具有小区的S-BCH并需要S-BCH以连接到网络;
*例3: UE不具有小区的S-BCH并需要S-BCH以保持空闲(并可能稍后
连接到网络)
(注意本文考虑在P-BCH上提供S-BCH调度信息的情况。诸如Ll/L2控制信号发送之类的提供S-BCH调度信息的其它方法也可以被顾及。)1.1例1: UE具有存储在存储器中的S-BCH并想要连接到网络
当UE具有存储器中所存储的S-BCH信息时,UE通常不需要重新读取同一小区的S-BCH,除非信息被更改了。如果信息未被更改,则稍后UE可以使用该S-BCH信息以开始诸如跟踪区域更新之类的过程。
这是"正常的"RACH过程,其中UE发送RACH并接收例如具有资源分配信息的RACH响应。
在此情况下,RACH前导中所使用的原因值或随机ID指示UE不需要S-BCH。
1.2例2: UE不具有S-BCH并需要S-BCH以连接到网络
当UE到达新小区并需要连接到网络例如以进行呼叫时,UE选择以下方式之一来获得S-BCH信息
a. 等待下一个定时S-BCH;
b. 通过发送RACH前导来请求按需S-BCH。
如果等待不影响UE想要执行的过程的执行,则UE可以等待下一个定时S-BCH 。
如果UE决定它不能等待定时S-BCH并想要请求按需S-BCH,则图4中所示的序列被提出。
1. 当空闲UE到达小区时,它读取固定的预定义P-BCH,该固定的预定义P-BCH将预占小区所必需的信息给予该UE。该P-BCH还可以提供可变S-BCH的调度信息。在该调度信息中,会指示下一个定时S-BCH将何时可用。UE可以基于该信息并且还基于UE想要执行的过程来决定是等待定时S-BCH还是请求待发送的按需S-BCH。
2. 假设UE需要进行呼叫并且等待下一个定时S-BCH的附加延迟不能接受,则UE将发送RACH以请求按需S-BCH传输并启动呼叫。这可以通过RACH前导中的原因值来指示。
3. eNB —接收到指示UE想要按需S-BCH并且然后继续另一过程的RACH,就为按需S-BCH调度资源并在P-BCH上广播该信息。eNB可能能够仅调度"呼叫建立"UE可能需要的系统信息,例如相邻小区信息。UE读取P-BCH以得到按需S-BCH的调度信息。
4. UE读取按需S-BCH。
5. eNB发送RACH响应以为UE分配资源。注意这不排除eNB同时发送RACH响应和按需S-BCH。
1.3例3: UE不具有S-BCH并需要S-BCH以保持空闲
这里,考虑当空闲UE到达小区并想要保持空闲的例子。UE需要读取S-BCH以便获得例如小区(重)选择参数和处于空闲状态所需的其它信息。
在这种情况下,与例2相同地,UE可能能够等待定时S-BCH。可替代地,UE可以决定它不能等待定时S-BCH并发送RACH以得到按需S-BCH。
针对按需S-BCH的情况提出图5的序列。
此过程和例2中的过程的不同之处为*步骤2中,RACH前导可以包含指示UE仅需要按需S-BCH并且不想继续连接到网络的原因值。*不需要RACH响应消息。2.优点
2.1 S-BCH资源节省
按需BCH机制的主要优点是当没有需要S-BCH传输的UE时其使网络能够节省S-BCH资源。
为了尝试并了解可能的节省,分析了特定时间间隔中按需S-BCH传输的概率。如果需要按需S-BCH的UE的平均到达率是每秒A个UE,则在T秒的时间间隔期间至少一个UE到达的概率是
P (N〉0)=l-e-AT
假设P-BCH提供按需S-BCH调度信息,即P-BCH的周期决定按需S-BCH传输的上限。如果T是P-BCH的周期,则P (N>0)是S-BCH占用率(occupancy),即其中按需S-BCH也被发送的P-BCH传输的部分。
现参考在NEC, NTTDoCoMo, RACH竞争和重试情况R2-062160中所提供的RACH流量模型,如果在使用6个非实时业务呼叫尝试的情况下,则当1000个UE预占小区时RACH尝试的数量是 每秒40个"正常的"RACH尝试。根据本文1.2和1.3部分中概述的过程,仅"正常的"RACH尝试总数的一部分会要求UE请求按需S-BCH。
在下面T=10ms的P-BCH时间间隔的图表中绘制了按需S-BCH占用率,这意味着按需S-BCH传输的最大速率等于10ms的定时S-BCH传输。图表还示出具有10ms和20ms的时间间隔的定时S-BCH的S-BCH占用率。x轴代表每秒到达的请求按需S-BCH的UE的数目。使用了最大范围80,其是前段所讨论的"正常的"RACH尝试值的2倍。
从图表看出,如果请求按需S-BCH的UE的到达率是40个UE每秒,则与10ms定时S-BCH相比,S-BCH占用率节省大约是70%。当与20ms定时S-BCH情况相比时,资源节省大约是35%,并且作为附加的好处,获取按需S-BCH的最大延迟减半。2.2对RACH的影响
对于例2,即UE不具有存储在存储器中的S-BCH并需要S-BCH以连接到网络,可以假设这不经常出现。可能对RACH载入和竞争有影响的按需S-BCH情境是例3,即UE想要S-BCH以保持空闲。
为了缓解由RACH竞争引起的问题,例3的UE可以被命令例如在等 待时间不超过某一阈值的情况下等待定时S-BCH。
此外,对于例3,即UE请求按需S-BCH并保持空闲,可以保留单个 RACH随机ID。以这种方式,即使当多于一个的UE出于同一目的同时发 送RACH时,这也不会造成针对S-BCH的任何竞争。eNB将认为这是单 个请求并正常地调度按需S-BCH。
为了进一步减少例3的RACH对整体RACH载入的影响,可以对使 得UE能够出于此目的而发送RACH的RACH分配进行限制。因为得到S-BCH传输的延迟对这些UE不是很紧要,所以这是可能的。 2.3定时(timing)关系和对呼叫建立延迟的影响
在UMTS中,由BCH调度时间间隔来限定与读取BCH信息有关的延 迟。为了最优化读取BCH的延迟和基站发射功率的消耗,需要这两个需 求间精细的平衡。通过所提出的定时S-BCH和按需S-BCH结合的机制, 两个需求间的平衡可以变得较不受约束(relaxed)。
在图7中示出了 RACH、 P-BCH和按需S-BCH间的定时关系。
RACH前导和包含按需S-BCH调度信息的P-BCH间的延迟不应多于 2ms,因为2ms是RACH前导和AICH [25.211]间的可比UMTS延迟。
从定时关系图可看出通过P-BCH的调度时间间隔,即按需S-BCH调 度信息的时间间隔,和可用RACH资源块间的时间间隔来限定读取按需S-BCH的延迟。
在UE到达率很高的情况下,避免过频繁地发送按需S-BCH的一种方 式是通过设定按需S-BCH调度信息时间间隔或RACH分配时间间隔来给 出最大的所期望按需S-BCH频率。 3.结论
下面提出了对传统3GPP信号发送的修改 *当UE经由非同步RACH或例如L2/L3信号发送之类的其它方式来发送 请求时,既定时地又按需地发送辅BCH。
图8示意性地示出移动(蜂窝)远程通信系统1,其中可实现上述的本发
ii明。在该示图中,UE是移动(蜂窝)电话(MT) 3-0、 3-1和3-2并且 eNB是基站5-1或5-2。移动电话3可以相互通信并经由基站5和电话网络 7来与其它用户通信。 基站
图9是示出本实施例中所使用的每个基站5的主要组件的框图。如所 示出的,每个基站5包括收发电路21,其可操作用于经由一个或多个天线 23来将信号发送到移动电话3并从移动电话3接收信号,并且其可操作用 于经由网络接口 25来将信号发送到电话网络7并从电话网络7接收信号。 控制器27根据存储在存储器29中的软件来控制收发电路21的操作。该软 件至少包括以上面所讨论的方式来控制基站的操作的操作系统31。
移动电话
图IO示意性地示出图8所示的每个移动电话3的主要组件。如所示出 的,移动电话3包括可操作用于经由一个或多个天线73来将信号发送到 基站5并从基站5接收信号的收发电路71。如所示出的,移动电话3还包 括控制器75,其控制移动电话3的操作,并且其与收发电路71相连接并 与扬声器77、麦克风79、显示器81和键盘83相连接。控制器75根据存 储在存储器85中的软件指令来进行操作。如所示出的,这些软件指令至 少包括以上面所讨论的方式来控制移动电话的操作的操作系统87。
权利要求
1. 一种传送移动远程通信系统的基站中的系统信息的方法,所述方法包括维护主系统信息;维护辅系统信息;定时地广播所述主系统信息;响应于触发事件,广播所述辅系统信息。
2. 根据前述权利要求的任一项所述的方法,其中,所述触发事件包括 从用户设备(UE)接收到对辅系统信息的请求。
3. 根据前述权利要求的任一项所述的方法,其中,响应于所述触发事 件,所述辅系统信息的广播被调度用于广播。
4. 根据前述权利要求的任一项所述的方法,其中,所述主系统信息包 括标识所述辅系统信息的下一次广播的调度信息,或者包括指向所述调度 信息的指针。
5. 根据权利要求3所述的方法,其中,所述调度信息包括时间和信道《曰息o
6. 根据权利要求3、 4或6所述的方法,其中,在没有触发事件的情 况下,所述辅系统信息的广播不被调度。
7. 根据前述权利要求的任一项所述的方法,其中,所述主系统信息以 定期的时间间隔被发送。
8. 根据前述权利要求的任一项所述的方法,其中,所述主系统信息包 括小区的标识符和一组小区无线电参数。
9. 根据前述权利要求的任一项所述的方法,其中,所述辅系统信息包 括相邻小区信息。
10. 根据前述权利要求的任一项所述的方法,其中,所述辅系统信息 的内容取决于触发的类型。
11. 根据前述权利要求的任一项所述的方法,其中,信道或码序列被 保留用于从用户设备对辅系统信息进行的请求,并且其中,对于从多于一 个的用户设备接收到交叠的请求,生成单个触发事件。
12. —种由移动远程通信系统的用户设备来获得系统信息的方法,所 述方法包括接收由小区广播的主系统信息;从所述主系统信息确定标识辅系统信息的广播的调度信息; 基于所确定的调度信息来接收所述辅系统信息。
13. 根据权利要求12所述的方法,包括在没有经调度的或已接收到的 辅系统信息的情况下,在空闲模式下等待所述辅系统信息的调度。
14. 根据权利要求12所述的方法,还包括在变换到活动模式后,在没 有已接收到的辅系统信息或调度信息的情况下,对辅系统信息进行请求。
15. 根据权利要求14所述的方法,其中,所述请求包括使用所保留的 信道或码序列来请求辅系统信息。
16. 根据权利要求12到15的任一项所述的方法,包括在接收到所广 播的主系统信息或辅系统信息后,对所存储的系统信息进行更新。
17. 根据权利要求12到16的任一项所述的方法,包括基于所接收到 的主系统信息来预占小区而不请求或接收辅系统信息。
18. —种包括被配置为执行根据权利要求1到11的任一项所述的方法 的无线电接口和传输调度器的基站。
19. 一种包括被配置为执行根据权利要求12到17的任一项所述的方 法的无线电接口和小区系统信息存储器的用户设备。
20. —种包括指令的计算机程序或计算机程序产品或计算机可读介 质,所述指令在被移动远程通信系统的处理组件执行时使所述系统执行根 据权利要求1到17的任一项所述的方法。
全文摘要
一种在移动远程通信系统的基站中使用的方法中,维护主系统信息并定时地广播主系统信息,同时响应于触发事件而广播辅系统信息。
文档编号H04W48/14GK101523957SQ20078003720
公开日2009年9月2日 申请日期2007年10月2日 优先权日2006年10月4日
发明者梦娜·穆斯塔法 申请人:日本电气株式会社
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1