zoukankan      html  css  js  c++  java
  • GSM公共控制信道

    GSM公共控制信道

    参考:百度百科 MSCBSC移动通信论坛 360百科

    GSM公共控制信道(CCCH)包括寻呼信道(PCH)、随机接入信道(RACH)、允许接入信道(AGCH)和小区广播控制信道(CBCH)。

    寻呼信道(PCH):用于寻呼移动台,是点对点的下行单向信道。

    Paging CHannel -- 寻呼信道

    前向码分多址信道中的一种代码信道,用于从基站向用户站传输控制信息和寻呼信息。这是一个下行信道,用于寻呼被叫的移动台,当网络想与某一移动台建立通信时,它会根据移动台当前登记的LAC区域内的所有小区通过PCH信道发送寻呼信息,标示为TMSI或IMSI。

    PCH(PAGING CHANNEL)是寻呼 寻呼信道是用于传送与寻呼过程相关数据的下行传输信道,用于网络与终端进行初始化时。最简单的一个例子是向终端发起语音呼叫,网络将使用终端所在小区的寻呼信道向终端发送寻呼消息。

    寻呼信道是用于传送与寻呼过程相关数据的下行传输信道,用于网络与终端进行初始化时。最简单的一个例子是向终端发起语音呼叫,网络将使用终端所在小区的寻呼信道向终端发送寻呼消息。

    当网络想与某一MS建立通信时,它就会根据MS所登记的LAC号向所有具有该LAC号的小区的PCH信道上进行寻呼,寻呼MS的标识为TMSI或IMSI。用于传输基站寻呼移动台的信息,寻呼信道属于下行信道,点对多点传播方式。

    在非组合CCCH的51复帧中共9个的CCCH块,其中包括PCH块和AGCH块.

    一般城市里AGCH设置为0,因为当PCH空闲时也可以做为AGCH来用.

    不同的PCH信道可以用于不同的寻呼组进行寻呼,组合信道寻呼组会减少,非组合会增多.寻呼组越多,用户需要等待时间越长.

    允许接入信道(AGCH):用于系统分配给该移动台的SDCCH,是下行单向信道,点对点通信。

    AGCH:允许接入信道。AGCH用于基站向随机接入成功的移动台发送指配了的独立专用控制信道SDCCH,下行信道。

    AGCH英文全称 Access Grant Channel,即允许接入信道。当网络收到处于空闲模式下的MS发出的信道请求后,就根据该请求需要分配一专用信道,AGCH通过根据该指配的描述(所分信道的描述,和接入的参数),向所有的移动台进行广播。接入许可信道属于下行信道,点对多点传播方式。

    小区广播信道(CBCH)是将信息(如地理位置、天气状况等信息)传到手机,再由用户选择接收的一种功能,通过此功能可向用户提供位置信息,天气预报等服务。

    CBCH是向中国移动的手机客户按区域、按频道发送各种实时、动态的分类信息的业务。它将使您的手机如同收音机一样,可以随时随地接收您感兴趣的频道内容,让您充分享受通信新生活。

    随机接入信道(RACH):用于移动台接入系统申请,移动台通过此信道申请SDCCH。它是上行单向信道,点对点通信。

    RACH(Random Access Channel)即随机接入信道,是一种上行传输信道。RACH在整个小区内进行接收,常用于PAGING回答和MS主叫/登录的接入等。

    折叠初始化

    初始化过程就是一个随机接入的过程。

    在任何情况下,如移动台需要同网络建立通信,都需通过RACH(随机接入信道)向网络发送一个报文来向系统申请一条信令信道,网络将根据信道请求需要来决定所分配的信道类型。这个在RACH 上发送的报文被称做"信道申请"(CHANNEL REQUEST),它其中的有用信令消息只有8bit,其中有3bit 用来提供接入网络原因的最少指示(3 个比特),如紧急呼叫、位置更新、响应寻呼或是主叫请求等,在网络拥塞的情况下,系统可根据这一粗略的指示来分别对待不同接入目的的信道申请(哪些类型的呼叫可接入网络、哪些类型的呼叫将被拒绝),并为它们选择分配最佳类型的信道。

    在这一指示中,由于信道容量的限制,显然不能将移动台想传送的所有信息全部发送给网络,如申请信道的具体原因、用户身份及移动设备的特性(这些消息在SABM 消息中发送)。

    另外5bit是移动台随机选择的鉴别符,它并不用来向网络提供信息,其目的是使网络能区别不同MS所发起的请求,网络此后将向移动台发送的"立即指配命令"(含有所分配信道的信息)中会再将该鉴别符发还给移动台,移动台通过网络返回的鉴别符和本身所发送的鉴别符相比较来判断该信息是否是网络发送给自己的。但它只有5bit,最多只能同时区分32 个MS,不保证两个同时发起呼叫的MS 的随机鉴别符一定不同。要进一步区别同时发起请求的MS,还要根据Um 接口上的应答消息。信道请求消息只在BSS 内部进行处理。

    传输

    随机接入信道的传输是基于带有快速捕获指示的时隙ALOHA方式。UE可以在一个预先定义的时间偏置开始传输,表示为接入时隙。每两帧有15个接入时隙,间隔为5120码片。接入时隙上的定时信息和捕获指示如7.3所示。图3显示了接入时隙的数量和它们之间的相互间隔。当前小区中哪个接入时隙的信息可用,是由高层信息给出的。

    图3: RACH接入时隙数量和间隔

    随机接入发射的结构如图4所示。随机接入发射包括一个或多个长为4096码片的前缀和一个长为10ms或20ms的消息部分。

    图4: 随机接入发射的结构

    折叠前缀部分

    随机接入的前缀部分长度为4096chips,是对长度为16chips的一个特征码(signature)的256次重复。总共有16个不同的特征码,具体参见[4]。

    折叠消息部分

    图5显示了随机接入的消息部分的结构。10ms的消息被分作15个时隙,每个时隙的长度为Tslot=2560chips。每个时隙包括两部分,一个是数据部分,RACH传输信道映射到这部分;另一个是控制部分,用来传送层1控制信息。数据和控制部分是并行发射传输的。一个10ms消息部分由一个无线帧组成,而一个20ms的消息部分是由两个连续的10ms无线帧组成。消息部分的长度可以由使用的特征码和/或接入时隙决定,这是由高层配置的。

    数据部分包括10*2^k个比特,其中k=0,1,2,3。对消息数据部分来说分别对应着扩频因子为256,128,64和32。

    控制部分包括8个已知的导频比特,用来支持用于相干检测的信道估计,以及2个TFCI比特,对消息控制部分

    图5:随机接入消息部分的结构

    来说这对应于扩频因子为256。导频比特模式如表8所示。在随机接入消息中TFCI比特的总数为15*2=30比特。TFCI值对应于当前随机接入消息的一个特定的传输格式。在PRACH消息部分长度为20ms的情况下,TFCI将在第2个无线帧中重复。

    图5:随机接入消息部分的结构

    表6: 随机接入消息的数据字段

    表6: 随机接入消息的数据字段

    时隙格式#i

    信道比特速率(kbps)

    信道符号速率(ksps)

    SF

    比特/

    比特/时隙

    Ndata

    0

    15

    15

    256

    150

    10

    10

    1

    30

    30

    128

    300

    20

    20

    2

    60

    60

    64

    600

    40

    40

    3

    120

    120

    32

    1200

    80

    80

    表7: 随机接入消息的控制字段

    时隙格式#i

    信道比特速率(kbps)

    信道符号速率(ksps)

    SF

    比特/

    比特/时隙

    Npilot

    NTFCI

    0

    15

    15

    256

    150

    10

    8

    2

    表 8: 用于RACH消息部分的导频比特模式,其中Npilot = 8

     

     

    Npilot= 8

    Bit #

    0

    1

    2

    3

    4

    5

    6

    7

    Slot #0

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

    14

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    0

    0

    0

    1

    1

    1

    1

    0

    1

    0

    1

    1

    0

    0

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    0

    1

    0

    0

    1

    1

    0

    1

    1

    1

    0

    0

    0

    0

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    0

    0

    0

    1

    0

    0

    1

    1

    0

    1

    0

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    1

    0

    0

    1

    0

    1

    0

    0

    0

    0

    1

    1

    1

    0

    1

    1

  • 相关阅读:
    20191017-1 每周例行报告
    20191010-2 每周例行报告
    20190919-1 每周例行报告
    彭思雨20190919-3效能分析
    zipfile
    subprocess
    configparser
    hashlib
    json & pickle
    headpq
  • 原文地址:https://www.cnblogs.com/mway/p/8168802.html
Copyright © 2011-2022 走看看