ISUP消息中rel原因值
G3.1正常类别
原因NO.1：未分配的（未确定的）号码
"unassigned (unallocaled) number"
该原因表示不能到达主叫用户所请求的终点，因为虽然号码格式有效，但该号码目前尚未分配（未确定）。
原因NO.2：无路由到达规定的转换网络（国内使用）
"no route to specified transit network(nationaluse)"
unallocaled(unassigned) number
该原因表示发送该原因的设备已经收到一个通过特定未被识别的转接网络迂回呼叫的请求。发送该原因的设备不能识别该转接网络是因为该转接网络不存在或当它存在时并没有未该设备提供服务。
是否支持该原因由网络决定。
原因NO.3无路由到达终点
"no route to destination"
该原因表示不能到达被叫用户，因为呼叫所经过的网络不为所希望的终点提供服务。
是否支持该原因由网络决定。
原因NO.4发送特殊的信息音
"send special information tone"
该原因表示不能达到被叫用户的原因在于应向主叫用户返回特殊信息音。
原因NO.5转接前缀拨号错误（国内使用）
"misdialled trunk prefix(national use)"
该原因表示被叫方号码的转接前缀错误内含。
原因NO.6：不可接受的通路
"chnnel unacceptable"
该原因表示发送实体在呼叫中不接受使用最新标识的通路。
原因NO.7：呼叫已给出并正在已建立的通路上递交
"call awarded and being delivered in an established channel"
该原因表示已给予用户来呼叫，并表示这一来呼叫在已建立的通路上与类似的呼叫一起正在被连接到该用户。
原因NO.8：先占
"preemption"
该原因表示呼叫正在被预先占有。
原因NO.9：先占电路留作重新使用
"preemption-circuit reserved for reuse"
该原因表示呼叫正在被预先占有，电路留作先点交换的重新使用。
原因NO.16：正常的呼叫清除
"normal call clearing"
该原因表示呼叫正在被清除，这是因为呼叫所涉及的用户之一已经请求清除呼叫。
在正常情况下，网络不发送这一原因。
原因NO.17：用户忙
"user busy"
当被叫用户指示不能接受另一个呼叫时使用这一原因。
原因NO.18：无用户响应
"no user responding"
当被叫用户在规定的时间周期内不用提醒或连接指示响应呼叫建立消息时使用这一原因。原因NO.19：无用户应答（用户已提醒）
"no answer from user(user alerted)"
当用户在规定的时间周期内提供提醒指示但未提供连接指示时使用这一原因。
注－该原因不一定由Q.931程序产生，而可能由内部网络定时器产生。
原因NO.20：用户缺席
"subscriber absent"
该原因用作移动应用，本规范暂不使用。
原因NO.21：呼叫拒绝
"call rejected"
该原因表示发送这一原因的设备不希望接收呼叫，虽然它可以接受呼叫，因为发送该原因的设备既不忙，也兼容。
该原因可以由网络产生，表示由于补充业务的限制而清除了呼叫。诊断字段可能包含有关补充业务的附加信息和拒绝原因。
原因NO.22：号码变更
"number changed"
当主叫用户所指示的被叫用户号码不再被分配时，该原因被返回到主叫用户。新的被叫用户号码可以作为任选项目包含在诊断字段中。如果网络不支持这种能力，将使用原因NO.1未分配的（未确定）的号码。
原因NO.26：清除未选择的用户
"non-selected user clearing"
该原因表示未给予用户来呼叫。
原因NO.27：终点故障
"destination out of order"
该原因表示不能到达用户所指示的收端，因为收端的接口工作不正常。术语"工作不正常"表示信令消息不能递交到远端用户；例如，远端用户的物理层或数据层故障，用户设备脱机等。
原因NO.28：无效的号码格式（不完整号码）
"invalid number format(incomplete number)"
该原因表示不能到达被叫用户因为被叫用户号码的格式无效或被叫用户号码不完整。
原因NO.29：性能被拒绝
"facility rejected"
当网络不能提供用户所请求的性能时则返回这一原则。
原因NO.30：对STATUS ENQUIRY的响应
"response to STATUS ENQUIRY"
当产生STATUS消息的原因是先接收到一条STA TUS ENQUIRY消息时，该原因被包含在
STA TUS消息中。
原因NO.31：正常，未规定
"normal,unspecified"
仅在正常原因类别中无其它原因适用时，使用该原因报告一个正常事件。
G3.2无可用的资源类别
原因NO.34：无可用的电路/通路
"no circuit'channel available"
该原因表示目前尚无适当的电路/通路可用来处理呼叫。
原因NO.38：网络失序
"network out of order"
该原因表示网络运行不正确，并且条件可能会持续相当长的时间；例如，立刻重新发起呼叫可能不会成功。
原因NO.39：永久帧方式连接未开放业务
"permanent frame mode connection out-of -service"
原因包含在STATUS消息表示一个永久建立帧方式连接未开放业务（例如，由于设备或部分故障）。
注－该原因在本标准中暂不使用。
原因NO.40：永久帧方式连接可运营
"permanent frame mode connection operational"
该原因包含在STA TUS消息表示一个永久建立帧方式连接是可运营的，并且可以传递用户信息。
注－该原因在本标准中暂不使用。
原因NO.41：临时故障
"temporary failure"
该原因表示网络工作不正常，并且这一状态不可能持续很长时间，例如，用户几乎可能立即希望进行另一次试呼。
原因NO.42：交换设备拥塞
"switching equipment congestion"
该原因表示产生这一原因的交换设备正在历经高业务量周期。
原因NO.43：接入信息被丢弃
"access information discarded"
该原因表示网络不能向远端用户按要求递交接入信息：即，如诊断中所指示的用户－用户信息，低层兼容性，高层兼容性或子地址。
应用注意所丢弃的某种接入信息作为任选项目被包含在诊断中。
原因NO.44：请求的电路/通路不可用
"requested circuit/channel not available"
当另一侧接口不能提供请求实体所指示的电路或通路时，返回这一原因。
原因NO.46：优先呼叫阻塞
"precedence call blocked"
该原因表示没有优先电路，或者被叫用户忙，并且其呼叫由相同或更高的优先级。
原因NO.47：资源不可用，未规定
"resource unavailable,unspecified"
该原因仅在没有任何其它的资源不可用类型使用时报告一个资源不可用的事件。
G3.3无适用的业务或任选项目类别
原因NO.49：业务质量不可用
"quality of service not available"
该原因用来报告所申请的建议X.213中定义的业务质量不能提供（例如，不能支持吞吐量或转接延迟）。
原因NO.50：未预订所请求的性能
"requested facility not subscribed"
该原因表示网络不能提供所请求的补充业务，因为用户没有完成支持业务的网络所必要的管理手续。
原因NO.53：CUG内呼出呼叫阻塞
"outgoing calls barred within CUG"
该原因表示虽然主叫方是可以呼出CUG呼叫的CUG成员，但CUG的该成员不允许呼出呼叫。
原因NO.55：CUG内呼入呼叫阻塞
"incoming calls barred within CUG"
该原因表示虽然被叫方是可以接收呼入CUG呼叫的CUG成员，但CUG的该成员不允许接收呼入呼叫。
原因NO.57：承载能力未认可
"bearer capability not authorised"
该原因表示，虽然产生该原因的设备已实施了用户请求的承载能力，但用户未被认可使用。原因NO.58：目前尚无可用的承载能力
"bearer capability not presently available"
该原因表示，虽然产生该原因的设备已实施了用户请求的承载能力，但此时无可用的承载能力。
原因NO.62：分配的呼出接入信息与用户级别不一致
"inconsistency in designated outgoing access information and subscriber class"
该原因表示在分配的呼出接入信息与用户级别之间存在不一致。
原因NO.63：无适用的业务或任选项目，未规定
"service or option not available, unspecified"
仅在无适用的业务或任选项目类别中无其它原因使用时，使用该原因报告无适用的业务或任选项目事件。
G3.4业务或任选项目未实施类别
原因NO.65：承载能力未实施
"bearer capability not implemented"
该原因表示发送这一原因的设备不支持所请求的承载能力。
原因NO.66：通路类型未实施
"channel type not implemented"
该原因表示发送这一原因的设备不支持所请求的类型。
原因NO.69：请求的性能未实施
"requested facility not implemented"
该原因表示发送这一原因的设备不支持所请求的补充业务。
原因NO.70：只有受限的数字信息承载可用（国内使用）
"only restricted digital information bearer capability is available(national use)"
该原因表示主叫方已申请了一个不受限的承载业务，但是发送该原因的设备仅支持所请求的承载能力中受限形式。
原因NO.79：业务或任选未实施，未规定
"service or option not implementaed,unspecified"
该原因用作仅当业务或任选未实施类别中无其它原因使用时报告一个业务或任选未实施事件。
G3.5无效的消息（例如，参数超出范围）类别
原因NO.81：无效的呼叫参考值
"invlalid call reference value"
该原因表示发送这一原因的设备所收到的消息带有不是在用户－网络接口现行使用的呼叫参考。
原因NO.82：所标识的通路不存在
"identfied channel does not exist"
原因表示发送这一原因的设备接收到一个呼叫请求，请求使用在接口处未被激活的通路。例如，如果用户预订了一次群接口的第1到12条通路，而用户设备或网络企图使用第13至23条通路，则产生这一原因。
原因NO.83：存在暂停的呼叫，但无所用的呼叫身份
"a suspended call exists,but this call identity does not"
该原因表示呼叫试图恢复时使用的呼叫身份与现行呼叫暂停时使用的呼叫身份不相同。
原因NO.84：呼叫身份在使用
"call identity in use"
该原因表示网络已接收到一个呼叫暂停的请求，这一呼叫暂停请求包含在有可能恢复呼叫的接口范围内一个暂停呼叫已经使用的呼叫身份（包括无呼叫身份）。
原因NO.85：我呼叫暂停
"no call suspended"
该原因表示网络已接收到一个呼叫恢复请求。呼叫恢复请求包含一个呼叫身份信息单元，该信息单元在有可能恢复呼叫的接口范围内目前未指示任何暂停的呼叫。
原因NO.86：具有所请求的呼叫身份的呼叫已被清除
"call having the requested call identity has been cleared"
该原因表示网络已接收到一个呼叫恢复请求。呼叫恢复请求包含一个呼叫身份信息单元指示的一个暂停的呼叫在暂停时已经被清除（网络超时或者由远端用户清除）
原因NO.87：用户不是CUG成员
"user not member of CUG"
该原因表示一个呼入的CUG呼叫的被叫用户不是一个特定CUG的成员或者主叫用户只是一个一用户呼叫一个CUG成员。
原因NO.88不兼容的特点
"incompatible destination"
该原因表示发送这一原因的设备已经接收到了一个建立呼叫的请求，该呼叫具有不能适用的低层兼容性，高层兼容性或其它兼容属性（例如，数据速率）。
原因NO.90不存在的CUG
"non-existent CUG"
该原因表示一个特定的CUG不存在。
原因NO.91无效的转接网络选择
"invalid transit netword selection(national use)"
该原因表示收到的转接网络识别符不是附录C中定义的正确的格式。
原因NO.95无效的消息，未规定
"invalid message,unspecified"
该原因仅当无效消息类别中无其它原因使用时报告一个无效消息事件。
G3.6协议差错（例如，未知的消息）类别
原因NO.96：必选信息单元丢失
"mandatory information element is missing"
该原因表示发送这一原因的设备已经接收到一条丢失信息单元的消息。而这一信息单元必须在处理该消息之前存在。
原因NO.97：消息类型不存在或未实施
"message type non-existent or not implemented"
该原因表示发送这一原因的设备已经接收到一条消息类型不可识别的消息，这是因为该消息未被定义，或者虽然定义了这一消息，但发送该消息的设备没有实施。
原因NO.98：消息与呼叫状态不符或消息类型不存在或未实施
"message not complatible with call state or message type non-existent or not implemented"
该原因表示发送这一原因的设备已经接收到一条消息，程序指示这是在呼叫状态期间不允许收的消息，或者发送这一原因的设备接收到一条STATUS消息，指示不兼容的呼叫状态。原因NO.99：信息单元不存在或未实施
"information element non-existent or not implemented"
该原因表示发送这一原因的设备已经接收到一条包含不可识别的信息单元的消息。这是因为该信息单元标识符未被定义或者虽然定义了这一信息单元。但发送该原因的设备没有实施。然而在发送该原因的设备处理这一消息时，不一定在消息中需要有这一信息单元。
原因NO.100：无效的信息单元内容
"invalid information element contents"
该原因表示发送这一原因的设备接收到一个已被实施的信息单元，但是发送这一原因的设备没有实施该信息单元中一个或多个字段的编码。
原因NO.101：消息与呼叫状态不符
"message not compatible with call state"
该原因表示接收到了一条与呼叫状态不符的消息。
原因NO.102：定时器超时的恢复
"recovery on timer expiry"
该原因表示由于定时器超时而启动了一个与Q.931差错处理程序相关的程序。
原因NO.103：参数不存在或未实施，通过（国内使用）
"parameter non-existent or not implemented-passed on (use)"
该原因表示发送该原因的设备已经收到一个消息，包含一个不可识别的参数，该参数不可识别是由于其未定义或定义了但该设备未实施。该原因指示该参数被忽略。另外，如果发送该原因的设备是在一个中间点，则该原因指示参数通过，未加改变。
原因NO.110：带不可识别的参数的消息，丢弃
"message with unrecognized parameter discarded"
该原因表示发送该原因的设备已经丢弃了包含一个不可识别的参数的消息。
原因NO.111：协议差错，未规定
"protocol error, unspecified"
仅在协议差错类别中无其它原因使用时，使用该原因报告协议差错事件。
G3.7互通类别
原因NO.127：互通，未规定
"interworking,unspecified"
该原因表示正在与一个不提供网络动作的原因的网络互通，这样就不能确定被发送的消息的准确原因。
1．某地主要由4173、4081小区覆盖，上述两个小区及相邻小区同属于LAC：13588。D T测试过程中，MS当前服务小区为4173，当检测到有Level 更强的邻区时，BSC指示MS切换（发起DL：HANDOVER COMMAND），此时发生了连续的三次切换失败（UL：HANDOVER FAILU RE）。虽然本例中经历了连续三次切换失败，MS仍然没有掉话（MS还在发送测量报告），但是对连续的切换失败应该给予很大的重视。导致连续的切换失败的原因可能是目标小区的T CH信道拥塞，也可能是目标小区的BCCH载频与TCH载频的发射功率没有调平，导致BCCH 与TCH的Level值相差很大而造成切换失败。 第三层信令消息流程: DL：HANDOVER COMMAND UL：HANDOVER ACCESS UL：HANDOVER COMPLETE UL：MEASUREMENT REPORT UL：HANDOVER FAILURE DL：SYSTEM INFORMATION TYPE 5 从切换的两个小区来看，4173向4081切换，是不同步切换，所以BSC应该在MS发出U L：HANDOVER ACCESS消息后，接着发出DL：PHYSICAL INFORMATION，指示MS切换至目标小区的Timing Advance，即MS与切换目标小区的距离。同时，在MS发出UL：HANDOVER COM PLETE之后，再发一条DL：PHYSICAL INFORMATION。在本例中BSC没有发出这两条消息，这也是导致发生切换失败的原因之一。 2．MS呼叫失败. 经检查信令发现有立即指派拒绝(immediate assignment reject)消息系统发现无可 用信道.很可能是因为系统拥塞引起的 3．一次正常的LAR&RAU信令流程如下： Direction Type Layer 3 Message UL RR Channel Request DL RR Immediate Assignment UL MM Location Updating Request UL RR Classmark Change UL RR GPRS Suspension Request DL MM Authentication Request UL MM Authentication Response DL MM Identity Request UL MM Identity Respone DL MM Location Updating accept UL MM TMSI Realocation Complete DL RR Channel Release UL GPRS MM Routing Area Update Request UL RR Channel Request
1. 在无失真的信源中，信源输出由H (X ) 来度量；在有失真的信源中，信源输出由R (D ) 来度量。 2. 要使通信系统做到传输信息有效、可靠和保密，必须首先信源编码，然后_加密_编码，再_信道编码，最后送入信道。 3. 带限AWGN 波形信道在平均功率受限条件下信道容量的基本公式，也就是有名的香农公式是C =W log(1+SNR ) ；当归一化信道容量C/W趋近于零时，也即信道完全丧失了通信能力，此时E b /N0为-1.6 dB ，我们将它称作香农限，是一切编码方式所能达到的理论极限。 4. 保密系统的密钥量越小，密钥熵H (K ) 就越小，其密文中含有的关于明文的信息量I (M ；C ) 就越大。 5. 已知n ＝7的循环码g (x ) =x 4+x 2+x +1，则信息位长度k 为，校验多项式h(x)= 3 6. 设输入符号表为X ＝{0，1}，输出符号表为Y ＝{0，1}。输入信号的概率分布为p ＝(1/2，1/2)，失真函数为d (0，0) = d (1，1) = 0，d (0，1) =2，d (1，0) = 1，则D min ＝0 ，?10??； D max ＝0.5 ，01??R (D min ) ＝1bit/symbol ，相应的编码器转移概率矩阵[p(y/x)]＝? R (D max ) ＝0 ，相应的编码器转移概率矩阵[p(y/x)]＝??10??。10?? 7. 已知用户A 的RSA 公开密钥(e,n )=(3,55)，p =5, q =11, 则φ(n ) = 40 ，他的秘密密钥(d,n ) ＝(27,55) 。若用户B 向用户A 发送m =2的加密消息，则该加密后的消息为8 。１．设Ｘ的取值受限于有限区间［a,b ］，则X 服从均匀分布时，其熵达到最大；如X 的均值为μ，方差受限为σ，则X 服从分布时，其熵达到最大。 2．信息论不等式：对于任意实数z >0，有ln z ≤z -1，当且仅当z =1时等式成立。 3．设信源为X={0，1}，P （0）=1/8，则信源的熵为1/8log 28+7/8log 2(7/8) ，如信源发出由m 个“0”和（100-m ）个“1”构成的序列，序列的自信息量为2m log 28+(100-m ) log 2(7/8) 。 4．离散对称信道输入等概率时，输出为等概分布。 5．根据码字所含的码元的个数，编码可分为定长编码和变长编码。 6．设DMS 为?u 2u 3u 4u 5u 6?U ??u 1?=. ，用二元符号表????P U ??0. 370. 250. 180. 100. 070. 03? X ={x 1=0, x 2=1}对其进行定长编码，若所编的码为{000，001，010，011，100，101}，则编码器输出码元的一维概率P (x 1) =, P (x 2) = 1. 在现代通信系统中，信源编码主要用于解决信息传输中的有效性，信道编码主要用于解决信息传输中的可靠性，加密编码主要用于解决信息传输中的安全性。 X ??x 1x 2x 3x 4?2. 离散信源?，则信源的熵为1.75bit/符号。=?p (x ) ??1/21/41/81/8?????
呼叫信令详解（前后台） 呼叫流程信令图 起呼过程分四个阶段：RRC连接建立，直传信令连接建立，RAB建立，震铃接通建立RRC连接 直传信令连接建立（含鉴权和加密）
RAB建立过程
振铃，接通 RRC建立过程 （1）UE 在取得下行同步后，向NodeB发送SYNC_UL，接收到NodeB 回应的FPACH 信息后，在RACH 信道上向RNC 发送RRC Connection Request 消息，发起RRC 连接建立过程。 （2）RNC 准备建立RRC 连接，分配建立RRC 连接所需要的资源，并发送一条Radio Link Setup Request 消息给NodeB。 （3）NodeB 配置物理信道，在新的物理信道上准备接收UE 消息，并给RNC 发送一条
Radio Link Setup Response 响应消息。 （4）RNC 通过ALCAP 协议，建立Iub 数据传输承载。Iub 数据传输承载通过AAL2 的绑定标识与DCH 绑定在一起。建立Iub 数据传输承载需要NodeB 确认。 （5）（6）通过Downlink Synchronisation 和Uplink Synchronisation. 控制帧，NodeB 与RNC 为Iub 数据传输承载建立同步，此后NodeB 开始DL 发送。（7）RNC 在FACH 信道上发送RRC Connection Setup 消息给UE。 （8）UE 在DCCH 上发送RRC Connection Setup Complete 消息给RNC，RRC 连接建立完成 建立初始直传/上下行直传 （9）UE 在DCCH 上给RNC 发送一条Initial Direct Transfer（CM Service Request）消息，该消息包括了UE 请求的业务类型等信息，例如12.2K语音业务。 （10）RNC 发起初始到CN 的信令连接，并发送一条Initial UE Message 消息给CN，通知CN 关于UE 请求的业务等内容。 通过初始直接传输过程后，可使用该信令连接传输UE 和CN 之间的NAS 消息。 （11）CN 发送RANAP 消息Direct Transfer （Authentication Request）到RNC，要求对UE 进行鉴权。 （12）RNC 发送RRC Downlink Direct Transfer（Authentication Request）消息给UE。NAS 消息由UTRAN 透明的传输到UE （13）UE 发送RRC Uplink Direct Transfer Message（Authentication Response）消息给RNC，告知网络侧UE 已经按照鉴权要求完成了鉴权。 （14）RNC 发送RANAP 消息Direct Transfer 给CN，将UE 的NAS消息转发给CN。NAS 消息被透明的传输到UTRAN。 安全模式控制 （15）CN 发送RANAP 消息Security Mode Command 给RNC，要求终端进行安全模式控制。 （16）RNC 在下行DCCH 上发送RRC Security Mode Command 给UE，开始/重启加密过程。 （17）UE 成功应用新的加密方式后，在上行DCCH 上发送RRC SecurityMode Complete 给RNC （18）RNC 发送RANAP 消息Security Mode Complete 给CN，双方完成安全模式控制。建立RAB （19）（20）（21）（22）上行和下行的直接传输过程，NAS 要求传输数据， UE 向网络侧说明Bearer Capability 以及Called Number 等内容。 （22）CN 向RNC 发送RANAP 消息Common ID，告知RNC 该UE 的IMSI。 （23）CN 向RNC 发送RANAP 消息Radio Access Bearer Assignment Request ，发起RAB
基本事件分析相关WinBUGS代码与数据(WinBUGS code and data to reproduce some base case analysis) 数据摘要： This directory contains the WinBUGS 1.4 code and data to reproduce the base case analysis presented in the paper. 中文关键词： 算法,统计,WinBUGSc代码,事件,分析, 英文关键词： algorithm,statistic,WinBUGSc code,case,analysis, 数据格式： TEXT 数据用途： design of the algorithm 数据详细介绍： WinBUGS code and data to reproduce some base case analysis
Data set information: This directory contains the WinBUGS 1.4 code and data to reproduce the base case analysis presented in the paper. BUGS model code--------------- Model code: agepw_model.txt Data files: icd-dat-age-mn-complete.txt, icd_ce_nice_data.txt Initial values: agepw_mn_complete_inits.txt Script: agepw_script.txt. The file paths in this script should be edited to match the place where you put the model, data and initial values. WBDev----------- The model code contains a new BUGS function, CE(), for calculating the expected cost and effectiveness from a Markov model in terms of multinomial logistic regression parameters (baseline log odds for the state on the next day, and log odds ratios for covariates governing the transition probabilities). This allows the complex matrix multiplications involved in the cost-effectiveness calculation to be performed very quickly, compared with writing them in BUGS model code. To use this new function, you must first install the WBDev interface, available from the WinBUGS Development site, https://www.doczj.com/doc/5a13264553.html,, and the Blackbox programming environment. This allows users to write new logical functions and univariate distributions for use in BUGS model code. Then place CE.txt, CEUtils.txt into the WBDev/Mod directory under the WinBUGS installation directory, usually c:/Program Files/WinBUGS14, and place Functions.txt into WBDev/Rsrc. Open all three of these files in Blackbox and save in Document (.odc) format in the same locations. Compile the files CE and CEUtils as instructed in the WBDev manual (menu Tools->Compile) and restart WinBUGS. Source: Christopher H. Jackson Medical Research Council Biostatistics Unit Institute of Public Health Forvie Site Robinson Way Cambridge
LTE路测问题分析归纳汇总 一、Probe测试需要重点关注参数 无线参数介绍 ?PCC:表示主载波，SCC：表示辅载波，目前LTE(R9版本)都采用单载波的，到4G（R10版本）有多载波联合技术就表示辅载波。 ?PCI:物理小区标示，范围（0-503）共计504个。 ?RSRP：参考信号接收电平，基站的发射功率，范围：-55 < RSRP <-75dbm。?RSSQ：参考信号接收质量，是RSRP和RSSI的比值，当然因为两者测量所基于的带宽可能不同，会用一个系数来调RSRQ=N*RSRP/RSSI。 ?RSSI：接收信号强度指示，表示UE所接收到所有信号的叠加。 ?SINR：信噪比，是接收到的有用信号的强度与接收到的干扰信号（噪声和干扰）的强度的比值，Average SINR>20 ?Transmission mode:传送模式，一共有8种，TM1表示单天线传送数据，TM2表示传输分集（2个天线传送相同的数据，在无线环境差（RSRP和SINR差）情况下，适合在边缘地带），TM3表示开环空间复用（2个天线传送不同的数据，速率可以提升1倍），TM4表示闭环环空间复用，TM5表示多用户 mimo,TM6表示rank=1的闭环预编码，TM7表示使用单天线口（单流BF），TM8表示双流BF。Transmission mode=TM3。
?Rank Indicator：表示层的意思，rank1表示单层，速率低，rank2表示2层，速率高。Rank Indicator = Rank 2 ?PDSCH RB number：表示该用户使用的RB数。这个值看出，该扇区下大概有几个用户。（20M带宽对应100个RB，15M带宽对应75个RB,10M带宽对应50个RB,5M带宽对应25个RB，3M带宽对应15个RB，1.4M带宽对应6个RB）多用户可以造成速率低原因之一。 ?PDCCH DL Grant Count：下行时域（子帧）调度数，PDCCH DL Grant Count >950。例如：上下行时域调度数的算法：一个无线帧是10ms，1s就有100个无线帧， 按5ms的转换周期，常规子帧上下行配比1:3，特殊子帧3:9:2来计算，每秒下行满调度数=3*100*2=600。每秒上行满调度数=1*100*2=200. 按5ms转换周期，常规子帧上下行配比1:3，特殊子帧10:2:2来计算，每秒下行满调度数=（3+1）*100*2=800。每秒上行满调度数=1*100*2=200；特殊子帧10:2:2时DwPTS也可以用来做下载。 ?PCC MAC ：下行MAC层速率：客户要求：PCC MAC>85Mbps。 ?Serving and Neighbor cells 这里最好是只显示serving cell，如果显示了neighbour cell，那么neighbour cell 的RSRP与serving cell的RSRP 相差15 dbm。 ?SRS:探测参考信号 天线测量介绍 ?TX antenna 2表示基站有2个发射天线。
第2章离散信息的度量 本章主要内容 （1）自信息的概念 （2）平均自信息的概念（信源熵的概念） （3）互信息的概念 （4）平均互信息的概念 （5）相对熵的概念 在通信系统中，信源发出的不同消息携带不同的信息量，不同的信源输出信息的能力也不同；同一消息通过载体信号在不同的信道中传输后，接收端获得的信息量不同，不同的信道传递信息的能力也不同。为了衡量一个通信系统质量好坏，必须有一些评价标准。例如误码率、接收信噪比、传信率等。而系统的传信率就是指单位时间内信道所传递的信息量。为了评价系统的传信率，必须对消息或信源所含有的信息有一个数量上的度量方法。这就是我们要研究信息度量的目的。 本章将介绍信息度量的一些基础概念。 2.1自信息 信源发出的消息的形式可以是语言、文字、公式、数据、声音、图像等等。信源发出信息，通过信道传送信息。假如学生上课时，教师在全部时间内仅反复说一句同样的话。显然，从后面教师（信源）发出的同一句话（消息）中，学生（信宿）得不到任何信息。同样的，把“2008年在北京召开了奥运会”这样一则消息告诉大家，那么大家也不会从中获得任何信息。从这些例子我们可以看出，学生要想再课堂上获得信息，必须要从教师那里学到事先不知道的知识。也就是说，对于信宿来说，使其获得解惑的是消息中的未知部分，借助通信，信宿明确了原来不明确的一些事情，获得了一些信息。一则消息包含有多少信息量，通过理想信道传输后信宿就可以获得多少信息量（或说消除了多少不确定性）。
2.1.1 自信息的定义 绪论中我们给出了香农对于信息的定义：信息是客观事物存在方式或运动状态的不确定性的描述。一般地说，信源要发出的消息的状态应该存在着某种程度的不确定性，通过通信，将信息传给了收信者，收信者得到信息之后，消除了不确定性。这里所说的不确定性，也就是随机性，不确定性程度可以直观地看成是猜测某些随机事件是否会发生的难易程度。我们可以用概率统计方法来描述随机事件发生后提供信息的大小。即概率大的事件，出现的可能性大，不确定性小，事件发生后带给我们的信息量就少。反之，小概率事件出现的可能性小，不确定性大，事件发生后带给我们的信息量就多。 定义2.1 随机事件i x 的自信息量定义为 ()log ()=-i r i I x p x （2.1） 由定义可以看出，随机事件所含信息量的多少用消息出现概率的对数的负值来表示。 下面我们借助通信过程的研究来分析自信息量的含义。对应在通信系统中，信源发出消息（符号）i x 的概率为()i p x ，则i x 含有的自信息量即为)(i x I ，正确传输，收信者就可以获得)(i x I 这么多的信息量。而通信过程发生前，信源发出的消息存在某种不确定性，借助通信，信宿明确了原来不明确的一些事情，获得了一些信息。通信过程消除掉的不确定性越多，信宿获得信息量就越大。所以通信系统中，自信息量)(i x I 的含义可以由两方面来理解： （1） 表示信源发出符号i x 前，发出符号i x 的不确定性的大小； （2） 表示信源发出符号i x 后，符号i x 提供的信息量的多少。 由定义我们可以绘制出自信息量的函数曲线如图2.1所示。
掉话类KPI 1.通过LST ALMAF查询站点实时告警,参考历史告警； 2.通过DSP BRD 查询单板运行情况； 3.提取两两小区切换，确定目标小区： A.确定目标小区运行情况，是否基站故障或异常告警； B.检查邻区间参数设置是否正确； C.通过Mapinfo检查小区邻区配置是否合理，进行邻区合理性优化； D.检查基站是否周边站点缺少，如为孤站，可视为正常； 4.检查参数设置是否合理： A.查询掉线类定时器设置是否正确；（T310、N311、N310、T311、T301）.如掉线率突 增，B.查询操作日志，确认是否有修改，导致小区异常； 5.检查是否存在干扰： A.通过Mapinfo查看小区PCI复用是否合理，是否存在模三冲突； B.检查小区时隙配比是否设置准确（室分:SA2\SSP7;宏站:SA2\SSP5）； C.如每PRB上干扰噪声平均值>-110dBm,确认小区存在上行干扰，同时可通过后台跟踪，确认干扰类型； 6.是否存在高质差： A.通过观察小区上下行丢包率是否正常，如丢包率偏高，基本断定小区存在质差； B. 通过后台误码率跟踪，如BLER>10%，确定小区存在高误码； 7.是否存在弱覆盖： A.检查传输模式，是否为TM3，如长时间为TM2，确认设置正确的情况下，基本确定小区存在弱覆盖； B. 对比64QAM和QPSK占比，如后者比例远大于前者,可确定小区覆盖异常； 8.现场测试及后台跟踪： A.安排前场人员现场测试，同时后台通过信令跟踪，配合查找问题原因； B.如果确认问题后，需第三方配合解决，转发相关人员处理，做好跟踪工作，直至问题闭环。 1、关于掉话的定义 话统掉话的定义 当ENodeB收到来自MME的ERAB ReleaseCommand（UE Context Release Command）消息或eNodeB向MME发送E-RAB RELEASE INDICATION（UE CONTEXT RELEASE REQUEST ）消息，且释放原因不为“Normal Release”，“User Inactivity”，“Partial Handover”，“Handover triggered”，“successful-handover”，“cs-fallback-triggered”时统计该指标。如果E-RAB RELEASE COMMAND消息中要求同时释放多个E-RAB，则相应指标按各个业务的QCI分别进行累加。
国家代码在...\config\world_names.csv Ctrl+F 搜索要找的国家 省份地区代码在...\config\province_names.csv Ctrl+F 搜索要找的省份地区 民族代号在...\config\world_names.csv Ctrl+F 搜索要找的民族 -------------------------------------------------------------------------------- command = { type = pop_research_mod which = capitalists value = 50 } #资本家command = { type = pop_research_mod which = clergymen value = 25 } #牧师 command = { type = pop_research_mod which = clerks value = 25 } #职员 某职业科技贡献率% command = { type = research_time value = -10 } #研究需要时间-10% command = { type = research_cost value = -10 } #研究需要点数-10% -------------------------------------------------------------------------------- command = { type = terminate_loans } #所有债务一笔勾销 command = { type = work_hour_eff value = 10 } #工作时效+10%（可增加效率，税收等）-------------------------------------------------------------------------------- command = { type = receiveprovince which = prov } #从某国得到某省区地 command = { type = receivestate which = prov when = 0 } #从某国得到某省（全省地区） （这里只要写省份代号就够了，国家不用写） command = { type = secedeprovince which = country value = provice } #把自己某省区地割让给某国 command = { type = secedestate which = country value = prov when = 0 } #把自己某省（全省地区）割让给某国 # 两国交战时 command = { type = control which = country value = province } # 把某省区地控制权给某国 command = { type = controlstate which = country value = prov } # 把某省（全省地区）控制权给某国 -------------------------------------------------------------------------------- command = { type = make_satellite which = [country tag] } #让某国成为你的卫星国 command = { type = end_satellite_mastery which = [country tag] } #取消某国是你的卫星国地位 command = { type = make_dominion which = [country tag] } #让某国成为你的仆从国 command = { type = end_dominion_mastery which = [country tag] }
TD-LTE测试内容和信令解析 1.测试内容 现阶段通常涉及到的测试按测试模式来分可分为室外测试与室内测试，按测试内容来分通常可分为覆盖测试与业务测试。由于室外与室内的覆盖测试及业务测试大部分操作都相同，所以本节以室外测试为例，介绍覆盖测试与业务测试的操作流程。 1.1覆盖测试 覆盖测试主要是通过CNT测试软件了解记录覆盖区域的信号强度、信号质量、信干噪比（SINR）。 1.1.1覆盖测试操作 通常进行覆盖测试时终端处于空闲状态，测试时先按上述文档介绍的内容进行正确的设备连接，开始记录测试文件，然后按既定路线进行路测，记录路线上的信号覆盖情况。 1.1.2覆盖测试关注指标 进行覆盖测试时，我们通常关注以下三个问题。第一，测试路段是哪个小区覆盖；第二，该路段覆盖信号强度如何；第三，该路段覆盖信号质量如何。 首先，从测试软件的LTE Cell Information窗口我们可以看到当前的主覆盖小区，如下图。 图15 LTE Cell Information窗口 正确导入小区信息数据后，我们可以在上图窗口中看到当前服务小区的名称，CellID和PCI，这些参数都能标识当前为终端提供服务的是哪个小区。更进一步，我们打开测试软件主菜单Presentation->LTE->LTE Server Cell Information窗口可以看到更详细的服务小区信息，如下图。
图16 LTE Server Cell Information窗口 确认了主服务小区之后，我们可以看到该小区在测试路段的覆盖强度，就是参数RSRP（参考信号接收功率），在图15和图16的两个窗口中均可以看到这个参数，更直观的方法，则是在MAP窗口通过路测覆盖图显示出来，如下图所示。 图17 RSRP覆盖图 现阶段道路覆盖要求RSRP尽量保持在-110dbm以上，为保证业务质量，作为优化的目标，我们尽可能的通过调整，使RSRP尽量保持在-105dbm以上。 对于覆盖路段的信号质量，目前软件不能采样较合适的参数直观显示。由于LTE小区间的干扰对信号质量影响较大，我们可以通过LTE Cell Information窗口的邻区信息间接获知信号质量的大概情况。根据LTE道路覆盖的要求，除正常的切换带外，最好LTE Cell Information 窗口只显示一个服务小区的信息（该窗口对邻区信号的显示有一定阀值控制，当主服务小区较邻区信号强很多的时候邻区信号不显示）。若该窗口中显示了几个小区的信号（如下图），信号强度相差不大，则表示该路段信号覆盖不纯净，信号质量较差。另外，对处于业务状态的终端，我们可以通过下行的BLER或上行的发射功率间接认识该处无线环境的信号质量。
层三信令掉话分析 1.前言 作为一名网优工程师, 需要牢牢掌握一个完整呼叫的信令流程. 我们做GSM优化, 主要是对Um口要把握的更深些. 尤其是Layer3信令－也就是我们平常做路测的工程师说的层3信令。关于层3信令，可以参考GSM规范04.08. 对层3信令的准确理解,可以帮助我们快速分析和定位网络问题. 2. 理论部分 2.1一次完整的主叫流程（含切换） IDLE： DL: SYSTEM INFORMA TION TYPE 1：包括小区信道描述和RACH控制参数 DL: SYSTEM INFORMA TION TYPE 2（2bis，2ter）：邻小区BCCH频点描述，RACH 控制信道，允许的PLMN（扩展邻小区BCCH频点描述+RACH控制信道；扩展邻小区BCCH 频点描述2） DL: SYSTEM INFORMA TION TYPE 3：CI，LAI，控制信道描述，小区选择，小区选择参数，RACH控制参数 DL: SYSTEM INFORMA TION TYPE 4：LAI，小区选择参数，RACH控制参数，CBCH 信道描述，CBCH移动配置 DL: SYSTEM INFORMA TION TYPE 7：小区重选参数 DL: SYSTEM INFORMA TION TYPE 8：小区重选参数 UL: Channel request DL: Immediate assignment（SDCCH） 试呼： UL:CM service request（如果后面直接收到System Information Type1，则视为起呼失败DL: CM service Request DL: CM service accept DL: AUTHENTICA TION REQUEST UL: AUTHENTICA TION RESPONSE DL: CIPHER MODE COMMAND UL: CIPHER MODE COMPLETE DL: TMSI REALLOCA TION COMMAND UL: TMSI REALLOCA TION COMPLETE UL: SETUP DL: CALL PROCEEDING DL: ASSIGNMENT COMMAND UL: ASSIGNMENT COMPLETE （TCH） DL: ALERTING 成功起呼： DL: CONNECT（呼叫成功的标志,） UL: CONNECT ACKNOWLEDGE DL: SYSTEM INFORMA TION TYPE 5（5bis，5ter）：邻近小区BCCH频点描述（扩展邻近小区BCCH频点描述） DL: SYSTEM INFORMA TION TYPE 6：CI，LAI，小区参数设置
一填空题 1、平均自信息为 表示信源的平均不确定度，也表示平均每个信源消息所提供的信息量。 平均互信息 表示从Y 获得的关于每个X 的平均信息量，也表示发X 前后Y 的平均不确定性减少的量，还表示通信前 后整个系统不确定性减少的量。 2、最大离散熵定理为：离散无记忆信源，等概率分布时熵最大,最大熵值为。 3、香农公式为 为保证足够大的信道容量，可采用（1）用频带换信噪比； （2）用信噪比换频带。 4、只要，当N 足够长时，一定存在一种无失真编码。 5、当R ＜C 时，只要码长足够长，一定能找到一种编码方法和译码规则，使译码错误概率无穷小。 6、1948年，美国数学家 香农 发表了题为“通信的数学理论”的长篇论文，从而创立了信息论。 7.人们研究信息论的目的是为了 高效、可靠、安全 地交换和利用各种各样的信息。 8.信息的 可度量性 是建立信息论的基础。 9.统计度量 是信息度量最常用的方法。 10、单符号离散信源一般用随机变量描述，而多符号离散信源一般用 随机矢量 描述。 11、一个随机事件发生某一结果后所带来的信息量称为自信息量，定义为 其发生概率对数的负值 。 12、自信息量的单位一般有 比特、奈特和哈特 。 13、必然事件的自信息是 0 。 14、不可能事件的自信息量是 ∞ 。 15、两个相互独立的随机变量的联合自信息量等于 两个自信息量之和 。 16、数据处理定理：当消息经过多级处理后，随着处理器数目的增多，输入消息与输出消息之间的平均互信息量 趋于变小 。 17、离散平稳无记忆信源X 的N 次扩展信源的熵等于离散信源X 的熵的 N 倍 。 18、离散平稳有记忆信源的极限熵，=∞H )/(lim 121-∞→N N N X X X X H 。 19、对于n 元m 阶马尔可夫信源，其状态空间共有 n m 个不同的状态。 20、一维连续随即变量X 在[a ，b]区间内均匀分布时，其信源熵为 log2（b-a ） 。
1. 概述 作为一名网优工程师, 需要牢牢掌握一个完整呼叫的信令流程. 我们做GSM优化, 主要是对Um 口要把握的更深些. 尤其是Layer3信令－也就是我们平常做路测的工程师说的层3信令。关于层3信令，可以参考GSM规范04.08. 对层3信令的准确理解,可以帮助我们快速分析和定位网络问题. 本期议题为“请举例说明如何结合层3信令分析路测中发现的问题”。讨论为期一个月，移动通信俱乐部的广大移友献计献策，对该议题进入了深入细致的讨论和分析，得出了大量具有实践意义的分析与心得。为此，特将其中精华部分加以总结归纳，形成该文档。 2. 理论部分 2.1一次完整的主叫流程（含切换） IDLE： DL: SYSTEM INFORMATION TYPE 1：包括小区信道描述和RACH控制参数 DL: SYSTEM INFORMATION TYPE 2（2bis，2ter）：邻小区BCCH频点描述，RACH控制信道，允许的PLMN（扩展邻小区BCCH频点描述+RACH控制信道；扩展邻小区BCCH频点描述2） DL: SYSTEM INFORMATION TYPE 3：CI，LAI，控制信道描述，小区选择，小区选择参数，RACH 控制参数 DL: SYSTEM INFORMATION TYPE 4：LAI，小区选择参数，RACH控制参数，CBCH信道描述，CBCH 移动配置 DL: SYSTEM INFORMATION TYPE 7：小区重选参数 DL: SYSTEM INFORMATION TYPE 8：小区重选参数 UL: Channel request DL: Immediate assignment（SDCCH） 试呼： UL:CM service request（如果后面直接收到System Information Type1，则视为起呼失败）DL: CM service Request DL: CM service accept DL: AUTHENTICATION REQUEST UL: AUTHENTICATION RESPONSE DL: CIPHER MODE COMMAND UL: CIPHER MODE COMPLETE DL: TMSI REALLOCATION COMMAND UL: TMSI REALLOCATION COMPLETE UL: SETUP 移动通信俱乐部 GSM 无线版专题讨论第五期 https://www.doczj.com/doc/5a13264553.html, 版权所有 2 DL: CALL PROCEEDING DL: ASSIGNMENT COMMAND UL: ASSIGNMENT COMPLETE （TCH） DL: ALERTING 成功起呼： DL: CONNECT（呼叫成功的标志,） UL: CONNECT ACKNOWLEDGE DL: SYSTEM INFORMATION TYPE 5（5bis，5ter）：邻近小区BCCH频点描述（扩展邻近小区BCCH 频点描述）
《信息论与编码》实验指导书 信息与通信工程学院信息工程系 2014年6月
目录 实验一绘制信源熵函数曲线 (3) 实验二哈夫曼编解码 (6) 实验三离散信道容量 (10)
1实验一绘制信源熵函数曲线 一、实验目的 1.掌握离散信源熵的原理和计算方法。 2.熟悉matlab软件的基本操作，练习应用matlab软件进行信源熵函数曲 线的绘制。 3.理解信源熵的物理意义，并能从信源熵函数曲线图上进行解释其物理意 义。 二、实验原理 1.离散信源相关的基本概念、原理和计算公式 产生离散信息的信源称为离散信源。离散信源只能产生有限种符号。 假定X是一个离散随机变量，即它的取值范围R={x1，x2，x3，…}是有限或可数的。设第i个变量x i发生的概率为p i=P{X=x i}。则： 定义一个随机事件的自信息量I（x i）为其对应的随机变量x i出现概率对数的负值。即： I（x i）= -log2p(x i) 定义随机事件X的平均不确定度H（X）为离散随机变量x i出现概率的数学期望，即： ∑∑ - = = i i i i i i x p x p x I x p X H) ( log ) ( ) ( ) ( ) ( 2 单位为比特/符号或比特/符号序列。 平均不确定度H（X）的定义公式与热力学中熵的表示形式相同，所以又把平均不确定度H（X）称为信源X的信源熵。 必须注意一下几点： a)某一信源，不管它是否输出符号，只有这些符号具有某些概率特性， 必有信源的熵值；这熵值是在总体平均上才有意义，因而是个确定 值，一般写成H（X），X是指随机变量的整体（包括概率分布）。 b)信息量则只有当信源输出符号而被接收者收到后，才有意义，这就 是给与信息者的信息度量，这值本身也可以是随机量，也可以与接
信令流程与GT翻译详解 MSC与HLR、MSC间进行通信，用到MTP、SCCP、TCAP、CAP各层协议栈，其中MTP层只识别各设备的信令点，SCCP层只识别MSC/VLR/GCR/SSP、HLR/AuC、SCP、SMSC等各个网元的设备识别码（俗称设备号），IMSI、MSISDN等。所以如果要实现MSC与HLR、MSC、SCP（智能网）等网元的通讯（信令流程传递的过程）。就要把SCCP层识别的MSC/VLR/GCR/SSP、HLR/AuC、SCP、SMSC设备识别码、IMSI、MSISDN翻译成相应网元信令点，实现个网元之间的通信和业务通信，即所谓的GT翻译（GT指向）。如下图所示即各个网元间的协议通信模型。 下面用位置更新流程中使用的IMSI，被叫分析流程中使用的MSISDN以及在各网元传递消息时使用的MSC/VLR/GCR/SSP、HLR/AuC、SCP、SMSC识别码，结合信令流程特点分析各网元间的GT翻译（即把各类转换成相应设备的信令点）是如何实现的。
图1：新用户开机位置更新与相关号码GT 翻译对应关系流程分析 1、新用户第一次开机，收到该小区的广播消息中携带的LAI+CGI 值，向网络侧发起位置更新请求消息，消息中携带IMSI 号码，LAI+CGI 信息。 2、MSC/VLR 根据手机上报的IMSI 号码，进行GT 翻译，找到该IMSI 所对应的归属HLR 信令点。并存储移动台的LAI （IMSI 号码对HLR 信令点的GT 翻 译） 、MSC 根据IMSI 翻译出的HLR 信令点向HLR 请求识别号，IMSI 、MSISDN 号码 4、HLR 记录该MSC/VLR 识别码，并建立该移动台IMSI 、MSISDN 号码与 MSC/VLR 识别码的对应关系。以便进行语音呼叫。（即移动台完成了HLR 里的位置登记） 图2 ：跨局位置更与相关号码对应关系流程分析 1、移动台漫游到MSC/VLR （2）局，收到该小区BCCH 信道广播消息中携带的LAI+CGI 值，发现与本移动台存储的LAI 值不符，触发位置更新请求，向MSC/VLR （2）请求位置更新，消息中携带该移动台的IMSI 号码 2、MSC/VLR （2）根据移动台上报的IMSI 号码，进行GT 翻译，找到该IMSI 所对应的归属HLR 信令点。并存储移动台的LAI 、MSC （2）向HLR 请求该用户的用户MSC/VLR IMSI 、MSISDN 号码 4、HLR 记录该MSC/VLR （2 ）识别码，并建立该移动台IMSI 、MSISDN 号码与（2）识别码的对应关系。以5、HLR 把该MSC/VLR （2）识别号码翻译成MSC/VLR （2）的信令点，找到该MSC/VLR （2），向MSC/VLR 插入该用户的用户数据。并在消息中携带该HLR 的识别号。 6、MSC/VLR （2)把HLR 识别号码翻译成HLR 信令点，向HLR 发送插入数据响应消息8、HLR 5、HLR 把该MSC/VLR 翻译成MSC/VLR 的信令点，找到该MSC/VLR ，向MSC/VLR 插入该用户的用户数据（HLR 中需要做的MSC/VLR 识别号与 MSC/VLR 信令点的GT 翻译） 7、HLR 根据记录的MSC/VLR （1）识别号，翻译成MSC/VLR （1）的信令点，向MSC(1)发送删除用户数据的消息。消息中携带HLR 识别号。