当前位置:文档之家› TD-LTE信令流程及信令解码

TD-LTE信令流程及信令解码

TD-LTE信令流程及信令解码
TD-LTE信令流程及信令解码

TD-LT信令流程及信令解码

TD-LTE信令流程及信令解码

(2013.03)

第1页共81页

TD-LT 信令流程及信令解码

第2页 共81页

本文主要就PS 业务建立流程和LTE 系统内切换的信令及信令解码进行重点IE 分析,并加以标注。所有信令为eNB 侧跟踪的信令。

1. PS 业务建立流程:

1.1 RRC Connection Request

UE 上行发送一条RRC Connection Request 消息给eNB,请求建立一条RRC 连接,该消息携带主要IE 有:

- ue-Identity :初始的UE 标识。如果上层提供S-TMSI ,侧该值为S-TMSI

;否则从

TD-LT 信令流程及信令解码

第3页 共81页

0…240-1中抽取一个随机值,设置为ue-Identity 。

- establishmentCause :建立原因。该原因值有emergency, highPriorityAccess, mt-Access, mo-Signalling, mo-Data, spare3, spare2, spare1。其中“mt”代表移动终端,“mo”代表移动始端。

信令解码如下:

-RRC-MSG : |_msg :

|_struUL-CCCH-Message : |_struUL-CCCH-Message : |_message : |_c1 :

|_rrcConnectionRequest : |_criticalExtensions :

|_rrcConnectionRequest-r8 : |_ue-Identity :

| |_randomValue : ----'0011000101001001011110110111100011000011'B(31 49 7B 78 C3 ) ----

|_establishmentCause : ---- highPriorityAccess(1) |_spare : ---- '0'B(00 ) 04 53 14 97 b7 8c 32

1.2 RRC Connection Setup

eNB 在下行方向发送RRCConnectionSetup 消息给UE ,包含建立SRB1承载和无线资源配置信息。该消息携带主要IE 详细见信令解码。 信令解码如下:

-RRC-MSG : |_msg :

|_struDL-CCCH-Message : |_struDL-CCCH-Message : |_message : |_c1 :

|_rrcConnectionSetup :

|_rrc-TransactionIdentifier : ---- 0x1(1) ----

|_criticalExtensions :

UE 初始标识,此处因为上层没有提供S-TMSI,所

建立原因,此处highPriorityAccess

TD-LT信令流程及信令解码

| |_logicalChannelGroup : ---- 0x0(0) ---- |_mac-MainConfig :

TD-LT 信令流程及信令解码

| |_p-a : ---- dB-3(2) ---- |_pucch-ConfigDedicated : | |_ackNackRepetition : | | |_release : ---- (0)

| |_tdd-AckNackFeedbackMode : ---- bundling(0) ---- |_pusch-ConfigDedicated :

| |_betaOffset-ACK-Index : ---- 0x9(9) ----

| |_betaOffset-RI-Index : ---- 0x5(5) ---- | |_betaOffset-CQI-Index : ---- 0xc(12) ---- |_uplinkPowerControlDedicated : | |_p0-UE-PUSCH : ---- 0x0(0) ---- | |_deltaMCS-Enabled : ---- en0(0) ---- | |_accumulationEnabled : ---- TRUE(1) ----

| |_p0-UE-PUCCH : ---- 0x0(0) ---- | |_pSRS-Offset : ---- 0x5(5) ---- | |_filterCoefficient : ---- fc6(6) ---- |_tpc-PDCCH-ConfigPUCCH : | |_release : ---- (0) |_tpc-PDCCH-ConfigPUSCH : | |_release : ---- (0) |_cqi-ReportConfig :

| |_cqi-ReportModeAperiodic : ---- rm30(3) ---- | |_nomPDSCH-RS-EPRE-Offset : ---- 0x0(0) ---- | |_cqi-ReportPeriodic : | |_setup :

| |_cqi-PUCCH-ResourceIndex : ---- 0x0(0) ---- | |_cqi-pmi-ConfigIndex : ---- 0x12(18) ----

| |_cqi-FormatIndicatorPeriodic :

| | |_widebandCQI : ---- (0)

| |_simultaneousAckNackAndCQI : ---- FALSE(0) ---- |_soundingRS-UL-ConfigDedicated :

| |_setup : | |_srs-Bandwidth : ---- bw2(2) ----

| |_srs-HoppingBandwidth : ---- hbw0(0) ---- | |_freqDomainPosition : ---- 0x0(0) ---- | |_duration : ---- TRUE(1) ---- | |_srs-ConfigIndex : ---- 0xa(10) ---- | |_transmissionComb : ---- 0x0(0) ---- | |_cyclicShift : ---- cs0(0) ----

表示使用的其中一种

TDD ACK/NACK 反馈模式

bundling

CQI 报告模式,值

参数Simultaneous-AN-and-CQI ,FALSE

表示PUCCH CQI 反馈类

CQI/PMI 上报的周期N P (子帧)和偏移值N OFFSET,CQIR ackNackRepetition

:ACK/NACK 重复,此处“release ”为清除此配置以及停止使用相关资

源。若设置为“setup

”,采用相应的接收配置以

TD-LT信令流程及信令解码

03 68 13 98 08 fd ce 01 83 b1 fa 73 1f 44 0a 03

00 1f fa 92 b9 86 14 c6 cc 00 01 23 00 81 40 14

00 01 c0

1.3RRC Connection Setup Complete

UE完成SRB1承载和无线资源的配置,向eNB发送RRC Connection Setup Complete 消息,包含NAS层Attach Request信息。携带主要IE有:

-selectedPLMN-Identity:表示UE从SIB1所包含的plmn-IdentyList中挑选出来的PLMN 识别号。如果从SIB1所包含的plmn-IdentyList中挑选出来的是第一个PLMN识别号,那么设置该值为1,如果挑选出来的是第二个PLMN识别号,则设置为2,诸如此类等等。

-registeredMME :UE所注册的MME的GUMMEI,由上层提供。

信令解码如下:

-RRC-MSG :

|_msg :

|_struUL-DCCH-Message :

|_struUL-DCCH-Message :

|_message :

|_c1 :

TD-LT 信令流程及信令解码

第7页 共81页

02 22 20 87 55 02 3f 17 a5 ad 87 fc 11 07 41 11 0b f6 64 f0 80 87 55 02 c0 b3 00 3a 04 e0 e0 00 00 00 1d 02 01 d0 11 27 17 80 80 21 10 01 01 00 10 81 06 00 00 00 00 83 06 00 00 00 00 00 0a 00 52 64 f0 80 00 03

1.4 Initial UE Message

eNB 选择MME ,向MME 发送INITIAL UE MESSAGE 消息,包含NAS 层Attach request 消息。该消息携带主要IE 有:

- eNB-UE-S1AP-ID : UE 在eNB 侧S1接口上的唯一标识,由eNB 分配。 - tAI :Tracking Area Identity ,用来标识一个跟踪区(TA )。

- eUTRAN-CGI :E-UTRAN Cell Global Identifier ,亦简称为ECGI ,小区全球唯一标识。

- rRC-Establishment-Cause :RRC 建立原因。 信令解码如下:

-S1ap-Msg :

|_initiatingMessage :

|_procedureCode : ---- 0xc(12) ---- |_criticality : ---- ignore(1) ---- |_value :

|_initialUEMessage : |_protocolIEs : |_SEQUENCE : | |_id : ---- 0x8(8) ---- | |_criticality : ---- reject(0) ---- | |_value :

| |_eNB-UE-S1AP-ID : ---- 0x133(307) ---- |_SEQUENCE :

| |_id : ---- 0x1a(26) ---- | |_criticality : ---- reject(0) ---- | |_value : | |_nAS-PDU :

eNB-UE-S1AP-ID ,在eNB

TD-LT 信令流程及信令解码

第8页 共81页

| |_NAS-MESSAGE :

| |_security-protected-NAS-message : | |_protected-nas : ----

0xA5AD87FC110741110BF664F080875502C0B3003A04E0E00000001D0201D01127178080211001010010810600000000830600000000000A005264F080000300 ---- |_SEQUENCE :

| |_id : ---- 0x43(67) ---- 0000000001000011 | |_criticality : ---- reject(0) ---- | |_value : | |_tAI :

| |_pLMNidentity : ---- 0x64F080 ---- | |_tAC : ---- 0x0003 ---- |_SEQUENCE :

| |_id : ---- 0x64(100) ---- | |_criticality : ---- ignore(1) ---- | |_value :

| |_eUTRAN-CGI :

| |_pLMNidentity : ---- 0x64F080 ----

| |_cell-ID : ---- '0000100111000101001000000001'B(09 C5 20 10 ) ---- |_SEQUENCE :

|_id : ---- 0x86(134) ---- |_criticality : ---- ignore(1) ---- |_value :

|_rRC-Establishment-Cause : ---- highPriorityAccess(1) ----

00 0c 40 69 00 00 05 00 08 00 03 40 01 33 00 1a 00 40 3f 17 a5 ad 87 fc 11 07 41 11 0b f6 64 f0 80 87 55 02 c0 b3 00 3a 04 e0 e0 00 00 00 1d 02 01 d0 11 27 17 80 80 21 10 01 01 00 10 81 06 00 00 00 00 83 06 00 00 00 00 00 0a 00 52 64 f0 80 00 03 00 43 00 06 00 64 f0 80 00 03 00 64 40 08 00 64 f0 80 09 c5 20 10 00 86 40 01 10

1.5 Initial Context Setup Request

MME 向eNB 发送initialContextSetupRequest 消息,请求建立初始的UE 上下文,包含E-RAB 上下文、安全密钥、切换限制列表、UE 无线性能以及UE 安全性能等等。 信令解码如下:

-S1ap-Msg :

|_initiatingMessage :

与RRCConnectionRequest 消息

TAI ,包含PLMNID 和

ECGI ,包含PLMNID 和cell-ID ,标识所在

TD-LT 信令流程及信令解码

第9页 共81页

|_procedureCode : ---- 0x9(9) ---- |_criticality : ---- reject(0) ---- |_value :

|_initialContextSetupRequest : |_protocolIEs : |_SEQUENCE : | |_id : ---- 0x0(0) ----

| |_criticality : ---- reject(0) ---- | |_value :

| |_mME-UE-S1AP-ID : ---- 0x2c01ec3(46145219) ---- |_SEQUENCE : | |_id : ---- 0x8(8) ----

| |_criticality : ---- reject(0) ---- | |_value :

| |_eNB-UE-S1AP-ID : ---- 0x133(307) ---- |_SEQUENCE :

| |_id : ---- 0x42(66) ---- | |_criticality : ---- reject(0) ---- | |_value :

| |_uEAggregateMaximumBitrate :

| |_uEaggregateMaximumBitRateDL : ---- 0x5f5e100(100000000) ---- | |_uEaggregateMaximumBitRateUL : ---- 0x5f5e100(100000000) ---- |_SEQUENCE :

| |_id : ---- 0x18(24) ---- | |_criticality : ---- reject(0) ---- | |_value :

| |_e-RABToBeSetupListCtxtSUReq : | |_SEQUENCE :

| |_id : ---- 0x34(52) ---- | |_criticality : ---- reject(0) ---- | |_value :

| |_e-RABToBeSetupItemCtxtSUReq : | |_e-RAB-ID : ---- 0x5(5) ----

| |_e-RABlevelQoSParameters : | | |_qCI : ---- 0x6(6) ---- | | |_allocationRetentionPriority :

| | |_priorityLevel : ---- highest(1) ---- | | |_pre-emptionCapability : ---- may-trigger-pre-emption(1) ---- | | |_pre-emptionVulnerability : ---- pre-emptable(1) ---- | |_transportLayerAddress : ---- '10011000110000100000101000001110'B(98 C2 0A 0E ) ---- | |_gTP-TEID : ---- 0xB0F80C6E ---- | |_nAS-PDU : | |_NAS-MESSAGE : 标识所请求建立

传输层地址

GTP 遂道终结点,此处指的是上行GTP 遂道终结点

与initialUEMessage

在MME 的S1接口

UE 的non-GBR 承载速率。当eNB 同时收到

uEAggregateMaximumBitrateDL 和uEAggregateMaximumBitrateUL ,

标识所使用

请求建立承载信息

分配资源的优先级配置(包括优先级和抢占指示器):

priorityLevel :此处为最高优先级,

如果配置为“

no priority ”,则不考虑下面两个参考的配置。

pre-emptionCapability :此处为"may-trigger-pre-emption

",表示分配可触发抢占过程。

pre-emptionVulnerability

:此处设置

TD-LT 信令流程及信令解码

第10页 共81页

| |_security-protected-and-ciphered-NAS-message : | |_protected-nas : ----

0x0791CCB407CC4B4F76084ADD73DB4301F6B6709532A63E05AB9035E84862FC021E5A493E5A5A296D7E69B053D0B8CC92A7E7569D948D2A43E20ADE80B1A103E5C21302E8520C6C3D826AFA58FD2BBD47B61C488976F4345EC99F7A9CB8564E140543C28DE CD7B908ABEC228D3B07E096FF7B00 ---- |_SEQUENCE :

| |_id : ---- 0x6b(107) ---- | |_criticality : ---- reject(0) ---- | |_value :

| |_uESecurityCapabilities :

| |_encryptionAlgorithms : ---- '1100000000000000'B(C0 00 ) ---- | |_integrityProtectionAlgorithms : ---- '1100000000000000'B(C0 00 ) ---- |_SEQUENCE :

| |_id : ---- 0x49(73) ---- 0000000001001001 | |_criticality : ---- reject(0) ---- | |_value :

| |_securityKey : ----

'0000101110101001011110100111111111100110110011010100010110110010111100001110101010111010001010100101000010000101010100000010000110000000011101110000100111101100011100111111000111010001110100010000110010000111101011100011100000011001100000000100010101001100'B(0B A9 7A 7F E6 CD 45 B2 F0 EA BA 2A 50 85 50 21 80 77 09 EC 73 F1 D1 D1 0C 87 AE 38 19 80 45 4C ) ----

|_SEQUENCE :

| |_id : ---- 0x19(25) ---- | |_criticality : ---- ignore(1) ---- | |_value :

| |_traceActivation :

| |_e-UTRAN-Trace-ID : ---- 0x64F0800050410000 ----

| |_interfacesToTrace : ---- '11100000'B(E0 ) ----

| |_traceDepth : ---- maximum(2) ----

| |_traceCollectionEntityIPAddress : ---- '00000000000000000000000000000000'B(00 00 00 00 ) ---- |_SEQUENCE :

|_id : ---- 0x29(41) ---- |_criticality : ---- ignore(1) ---- |_value :

|_handoverRestrictionList :

|_servingPLMN : ---- 0x64F080 ----

00 09 00 80 f7 00 00 08 00 00 00 05 c0 02 c0 1e c3 00 08 00 03 40 01 33 00 42 00 0a 18 05 f5 e1 00 60 05 f5 e1 00 00 18 00 80 88 00 00 34 00 80 82 45 00 06 07 0f 80 98 c2 0a 0e b0 f8 0c 6e 73 27 07 91 cc b4 07 cc 4b 4f 76 08 4a dd 73 db 43 01 f6 b6 70 95 32 a6 3e 05 ab 90 35 e8 48 62 fc

切换限制列表

安全密钥

UE 的安全性能:包括加密

跟踪激活 比特中每一位代表一个eNB 接口 第一个比特=S1-MME ,第二个比特 =X2,第三个比特 =Uu 其

度,

TD-LT信令流程及信令解码

02 1e 5a 49 3e 5a 5a 29 6d 7e 69 b0 53 d0 b8 cc

92 a7 e7 56 9d 94 8d 2a 43 e2 0a de 80 b1 a1 03

e5 c2 13 02 e8 52 0c 6c 3d 82 6a fa 58 fd 2b bd

47 b6 1c 48 89 76 f4 34 5e c9 9f 7a 9c b8 56 4e

14 05 43 c2 8d ec d7 b9 08 ab ec 22 8d 3b 07 e0

96 ff 7b 00 6b 00 05 18 00 0c 00 00 00 49 00 20

0b a9 7a 7f e6 cd 45 b2 f0 ea ba 2a 50 85 50 21

80 77 09 ec 73 f1 d1 d1 0c 87 ae 38 19 80 45 4c

00 19 40 10 00 64 f0 80 00 50 41 00 00 e0 20 f8

00 00 00 00 00 29 40 04 00 64 f0 80

1.6UE Capability Enquiry

eNB发送ueCapabilityEnquiry消息给UE,请求传输UE的无线接入性能。

信令解码如下:

-RRC-MSG :

|_msg :

|_struDL-DCCH-Message :

|_struDL-DCCH-Message :

|_message :

|_c1 :

01 3a 10 04 8d 00

1.7UE Capability Information

eNB接收到INITIAL CONTEXT SETUP REQUEST消息,如果不包含UE能力信息,则eNB向UE发送UECapabilityEnquiry消息,查询UE能力;携带主要IE有:

第11页共81页

TD-LT 信令流程及信令解码

rat-Type : RAT 类型。 信令解码如下:

-RRC-MSG : |_msg :

|_struUL-DCCH-Message : |_struUL-DCCH-Message : |_message : |_c1 :

|_ueCapabilityInformation :

|_rrc-TransactionIdentifier : ---- 0x1(1) ---- |_criticalExtensions : |_c1 :

|_ueCapabilityInformation-r8 : |_ue-CapabilityRAT-ContainerList : |_UE-CapabilityRAT-Container : |_rat-Type : ---- eutra(0) ---- |_ueCapabilityRAT-Container : |_ueEutraCap :

|_UE-EUTRA-Capability :

|_accessStratumRelease : ---- rel8(0) ---- |_ue-Category : ---- 0x3(3) ---- |_pdcp-Parameters :

| |_supportedROHC-Profiles :

| | |_profile0x0001 : ---- FALSE(0) ---- | | |_profile0x0002 : ---- FALSE(0) ---- | | |_profile0x0003 : ---- FALSE(0) ---- | | |_profile0x0004 : ---- FALSE(0) ---- | | |_profile0x0006 : ---- FALSE(0) ---- | | |_profile0x0101 : ---- FALSE(0) ---- | | |_profile0x0102 : ---- FALSE(0) ---- | | |_profile0x0103 : ---- FALSE(0) ---- | | |_profile0x0104 : ---- FALSE(0) ----

| |_maxNumberROHC-ContextSessions : ---- cs2(0) ---- |_phyLayerParameters :

以下是e-UTRA 的能力信息

TS 36.306定义的UE 分类。取值范围为UE 支持的并发激活ROHC 上下文的最大标识UE 所支持的网络能力,此处为UE 支

持EUTRA 网络。

如果该ue-CapabilityRequest 包含“geran-cs ”,并且如果UE 支持GERAN CS 域,那么在

TD-LT 信令流程及信令解码

第13页 共81页

| | |_halfDuplex : ---- FALSE(0) ---- | |_SupportedBandEUTRA :

| | |_bandEUTRA : ---- 0x26(38) ---- | | |_halfDuplex : ---- TRUE(1) ---- | |_SupportedBandEUTRA : | | |_bandEUTRA : ---- 0x28(40) ---- | | |_halfDuplex : ---- TRUE(1) ---- | |_SupportedBandEUTRA : | | |_bandEUTRA : ---- 0x29(41) ---- | | |_halfDuplex : ---- TRUE(1) ---- | |_SupportedBandEUTRA :

| |_bandEUTRA : ---- 0x7(7) ---- | |_halfDuplex : ---- FALSE(0) ---- |_measParameters : | |_bandListEUTRA : | |_BandInfoEUTRA : | | |_interFreqBandList : | | |_InterFreqBandInfo :

| | | |_interFreqNeedForGaps : ---- TRUE(1) ---- | | |_InterFreqBandInfo :

| | | |_interFreqNeedForGaps : ---- TRUE(1) ---- | | |_InterFreqBandInfo :

| | |_interFreqNeedForGaps : ---- TRUE(1) ---- | |_BandInfoEUTRA : | | |_interFreqBandList : | | |_InterFreqBandInfo :

| | | |_interFreqNeedForGaps : ---- TRUE(1) ---- | | |_InterFreqBandInfo :

| | | |_interFreqNeedForGaps : ---- TRUE(1) ---- | | |_InterFreqBandInfo :

| | |_interFreqNeedForGaps : ---- TRUE(1) ---- | |_BandInfoEUTRA : | | |_interFreqBandList : | | |_InterFreqBandInfo :

| | | |_interFreqNeedForGaps : ---- TRUE(1) ---- | | |_InterFreqBandInfo :

| | | |_interFreqNeedForGaps : ---- TRUE(1) ---- | | |_InterFreqBandInfo :

| | |_interFreqNeedForGaps : ---- TRUE(1) ---- | |_BandInfoEUTRA : | | |_interFreqBandList : | | |_InterFreqBandInfo :

| | | |_interFreqNeedForGaps : ---- TRUE(1) ----

bandEUTRA :TS 36.101【Table 5.5-1】中定义的E-UTRA 频带。例如:38对应2570 MHz – 2620 MHz

halfDuplex :半双工标识,如果为TURE ,那interFreqNeedForGaps :

表示当在bandListEUTRA 以及在interFreqBandList

TD-LT信令流程及信令解码

| | |_InterFreqBandInfo :

| | | |_interFreqNeedForGaps : ---- TRUE(1) ----

| | |_InterFreqBandInfo :

| | |_interFreqNeedForGaps : ---- TRUE(1) ----

| |_BandInfoEUTRA :

| |_interFreqBandList :

| |_InterFreqBandInfo :

| | |_interFreqNeedForGaps : ---- TRUE(1) ----

| |_InterFreqBandInfo :

| | |_interFreqNeedForGaps : ---- TRUE(1) ----

| |_InterFreqBandInfo :

| |_interFreqNeedForGaps : ---- TRUE(1) ----

|_featureGroupIndicators : ----

'11100110000011010001100010000000'B(E6 0D 18 80 ) ----

|_interRA T-Parameters : ---- (0) ----

02 3a 01 01 58 12 00 04 44 d2 e7 d1 18 20 2e 0b

82 e0 b8 2f cc 1a 31 00 00 00

1.8UE Capability Info Indication

eNB向MME发送uECapabilityInfoIndication ,更新MME的UE能力信息。分析同ueCapabilityInformation。

信令解码如下:

-S1ap-Msg :

|_initiatingMessage :

|_procedureCode : ---- 0x16(22) ----

|_criticality : ---- ignore(1) ----

|_value :

|_uECapabilityInfoIndication :

|_protocolIEs :

|_SEQUENCE :

| |_id : ---- 0x0(0) ----

| |_criticality : ---- reject(0) ----

| |_value :

| |_mME-UE-S1AP-ID : ---- 0x2c01ec3(46145219) ----

|_SEQUENCE :

| |_id : ---- 0x8(8) ----

| |_criticality : ---- reject(0) ----

| |_value :

第14页共81页

TD-LT 信令流程及信令解码

| |_eNB-UE-S1AP-ID : ---- 0x133(307) ---- |_SEQUENCE :

|_id : ---- 0x4a(74) ---- |_criticality : ---- ignore(1) ---- |_value :

|_uERadioCapability :

|_UERadioAccessCapabilityInformation : |_criticalExtensions : |_c1 :

|_ueRadioAccessCapabilityInformation-r8 : |_ue-RadioAccessCapabilityInfo : |_UECapabilityInformation :

|_rrc-TransactionIdentifier : ---- 0x1(1) ---- |_criticalExtensions : |_c1 :

|_ueCapabilityInformation-r8 : |_ue-CapabilityRAT-ContainerList : |_UE-CapabilityRAT-Container : |_rat-Type : ---- eutra(0) ---- |_ueEutraCap :

|_UE-EUTRA-Capability :

|_accessStratumRelease : ---- rel8(0) ---- |_ue-Category : ---- 0x3(3) ----

|_pdcp-Parameters :

| |_supportedROHC-Profiles :

| | |_profile0x0001 : ---- FALSE(0) ---- | | |_profile0x0002 : ---- FALSE(0) ---- | | |_profile0x0003 : ---- FALSE(0) ---- | | |_profile0x0004 : ---- FALSE(0) ---- | | |_profile0x0006 : ---- FALSE(0) ---- | | |_profile0x0101 : ---- FALSE(0) ---- | | |_profile0x0102 : ---- FALSE(0) ---- | | |_profile0x0103 : ---- FALSE(0) ---- | | |_profile0x0104 : ---- FALSE(0) ----

| |_maxNumberROHC-ContextSessions : ---- cs2(0) |_phyLayerParameters :

| |_ue-TxAntennaSelectionSupported : ---- FALSE(0) | |_ue-SpecificRefSigsSupported : ---- TRUE(1) ---- |_rf-Parameters :

| |_supportedBandListEUTRA : 标识UE 所支持的网络能力,此处为UE TS 36.306定义的UE 分类。 UE 支持的并发激活ROHC 上下文的最大

ue-TxAntennaSelectionSupported :该值如果为TURE ,则表示UE 有能力支持TS 36.213[8.7]中所描述的UE 传输天线选择。

TD-LT 信令流程及信令解码

第16页 共81页

| | |_halfDuplex : ---- FALSE(0) ---- | |_SupportedBandEUTRA :

| | |_bandEUTRA : ---- 0x26(38) ---- | | |_halfDuplex : ---- TRUE(1) ---- | |_SupportedBandEUTRA :

| | |_bandEUTRA : ---- 0x28(40) ---- | | |_halfDuplex : ---- TRUE(1) ---- | |_SupportedBandEUTRA :

| | |_bandEUTRA : ---- 0x29(41) ---- | | |_halfDuplex : ---- TRUE(1) ---- | |_SupportedBandEUTRA : | |_bandEUTRA : ---- 0x7(7) ---- | |_halfDuplex : ---- FALSE(0) ---- |_measParameters : | |_bandListEUTRA : | |_BandInfoEUTRA : | | |_interFreqBandList : | | |_InterFreqBandInfo :

| | | |_interFreqNeedForGaps : ---- TRUE(1) | | |_InterFreqBandInfo :

| | | |_interFreqNeedForGaps : ---- TRUE(1) | | |_InterFreqBandInfo :

| | |_interFreqNeedForGaps : ---- TRUE(1) | |_BandInfoEUTRA : | | |_interFreqBandList : | | |_InterFreqBandInfo :

| | | |_interFreqNeedForGaps : ---- TRUE(1) | | |_InterFreqBandInfo :

| | | |_interFreqNeedForGaps : ---- TRUE(1) | | |_InterFreqBandInfo :

| | |_interFreqNeedForGaps : ---- TRUE(1) | |_BandInfoEUTRA : | | |_interFreqBandList : | | |_InterFreqBandInfo :

| | | |_interFreqNeedForGaps : ---- TRUE(1) | | |_InterFreqBandInfo :

| | | |_interFreqNeedForGaps : ---- TRUE(1) | | |_InterFreqBandInfo :

| | |_interFreqNeedForGaps : ---- TRUE(1) | |_BandInfoEUTRA : | | |_interFreqBandList : | | |_InterFreqBandInfo :

| | | |_interFreqNeedForGaps : ---- TRUE(1)

interFreqNeedForGaps :表示当在

bandListEUTRA 以及在interFreqBandList 中

TD-LT信令流程及信令解码

| | |_InterFreqBandInfo :

| | | |_interFreqNeedForGaps : ---- TRUE(1)

| | |_InterFreqBandInfo :

| | |_interFreqNeedForGaps : ---- TRUE(1)

| |_BandInfoEUTRA :

| |_interFreqBandList :

| |_InterFreqBandInfo :

| | |_interFreqNeedForGaps : ---- TRUE(1)

| |_InterFreqBandInfo :

| | |_interFreqNeedForGaps : ---- TRUE(1)

| |_InterFreqBandInfo :

| |_interFreqNeedForGaps : ---- TRUE(1)

|_featureGroupIndicators : ----

'11100110000011010001100010000000'B(E6 0D 18 80 ) ----

|_interRAT-Parameters : ---- (0) ----

00 16 40 32 00 00 03 00 00 00 05 c0 02 c0 1e c3

00 08 00 03 40 01 33 00 4a 40 1b 1a 00 c2 01 01

58 12 00 04 44 d2 e7 d1 18 20 2e 0b 82 e0 b8 2f

cc 1a 31 00 00 00

1.9Security Mode Command

eNB向UE发送securityModeCommand消息,目的是在RRC连接建立上激活AS安全。主要IE有:

-cipheringAlgorithm :指明SRB和DRB使用的加密算法,在TS 33.401(5.1.3.2节)有描述。取值为{ eea0, eea1, eea2, spare5, spare4, spare3, spare2, spare1, ...};

-integrityProtAlgorithm:指明SRB使用的完整性保护算法,在TS 33.401(5.1.4.2节)中有描述。取值为{eia0-v920, eia1, eia2, spare5, spare4, spare3, spare2, spare1, ...}

信令解码如下:

-RRC-MSG :

|_msg :

|_struDL-DCCH-Message :

|_struDL-DCCH-Message :

第17页共81页

TD-LT 信令流程及信令解码

第18页 共81页

|_message : |_c1 :

|_securityModeCommand :

|_rrc-TransactionIdentifier : ---- 0x1(1) ---- |_criticalExtensions : |_c1 :

|_securityModeCommand-r8 : |_securityConfigSMC : |_securityAlgorithmConfig :

|_cipheringAlgorithm : ---- eea0(0) ---- |_integrityProtAlgorithm : ---- spare1(7) ----

01 32 00 70

1.10 RRC Connection Reconfiguration

eNB 向UE 发送rrcConnectionReconfiguration 消息,要求UE 进行相关无线资源重配,这里主要是为了建立SRB2与DRB 。分析见rrcConnectionSetup 消息 信令解码如下:

-RRC-MSG : |_msg :

|_struDL-DCCH-Message : |_struDL-DCCH-Message : |_message : |_c1 :

|_rrcConnectionReconfiguration :

|_rrc-TransactionIdentifier : ---- 0x1(1) ---- |_criticalExtensions : |_c1 :

|_rrcConnectionReconfiguration-r8 : |_dedicatedInfoNASList : | |_DedicatedInfoNAS : ----

0x270791CCB407CC4B4F76084ADD73DB4301F6B6709532A63E05AB9035E84862FC021E5A493E5A5A296D7E69B053D0B8CC92A7E7569D948D2A43E20ADE80B1A103E5C21302E8520C6C3D826AFA58FD2BBD47B61C488976F4345EC 99F7A9CB8564E140543C28DECD7B908ABEC228D3B07E096FF7B(00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ) ----

|_radioResourceConfigDedicated : |_srb-ToAddModList : 加密算法,当前采用的

完整性保护算法

TD-LT 信令流程及信令解码

第19页 共81页

| |_rlc-Config : | | |_explicitValue : | | |_am :

| | |_ul-AM-RLC :

| | | |_t-PollRetransmit : ---- ms45(8) ---- | | | |_pollPDU : ---- pInfinity(7) ---- | | | |_pollByte : ---- kBinfinity(14) ---- | | | |_maxRetxThreshold : ---- t32(7) ---- | | |_dl-AM-RLC :

| | |_t-Reordering : ---- ms35(7) ---- | | |_t-StatusProhibit : ---- ms0(0) ---- | |_logicalChannelConfig : | |_explicitValue :

| |_ul-SpecificParameters : | |_priority : ---- 0x3(3) ----

| |_prioritisedBitRate : ---- infinity(7) ---- | |_bucketSizeDuration : ---- ms300(3) ---- | |_logicalChannelGroup : ---- 0x0(0) ---- |_drb-ToAddModList : | |_DRB-ToAddMod :

| |_eps-BearerIdentity : ---- 0x5(5) ---- | |_drb-Identity : ---- 0x1(1) ---- | |_pdcp-Config :

| | |_discardTimer : ---- ms1500(6) ---- | | |_rlc-AM :

| | | |_statusReportRequired : ---- TRUE(1) ---- | | |_headerCompression : | | |_notUsed : ---- (0) | |_rlc-Config : | | |_am :

| | |_ul-AM-RLC :

| | | |_t-PollRetransmit : ---- ms40(7) ----

| | | |_pollPDU : ---- p32(3) ---- | | | |_pollByte : ---- kB25(0) ---- | | | |_maxRetxThreshold : ---- t32(7) ---- | | |_dl-AM-RLC :

| | |_t-Reordering : ---- ms50(10) ---- | | |_t-StatusProhibit : ---- ms50(10) ---- | |_logicalChannelIdentity : ---- 0x3(3) ---- | |_logicalChannelConfig : | |_ul-SpecificParameters : | |_priority : ---- 0x9(9) ----

| |_prioritisedBitRate : ---- kBps8(1) ----

SRB2的RLC 配置 SRB2的逻辑信道配置 此处为建立DRB EPS 承载标识

DRB 标识 丢弃定时器,当超时,丢弃与表示重建立PDCP 实体时,UE 是否要发送一个PDCP 状态报NoUsed 表示不使用头压缩 DRB 的RLC 配置,分析同

DRB 的逻辑信道配置,分析同

TD-LT 信令流程及信令解码

第20页 共81页

| |_bucketSizeDuration : ---- ms300(3) ---- | |_logicalChannelGroup : ---- 0x3(3) ---- |_mac-MainConfig : | |_explicitValue :

| |_ul-SCH-Config : | | |_periodicBSR-Timer : ---- sf10(1) ---- | | |_retxBSR-Timer : ---- sf320(0) ---- | | |_ttiBundling : ---- FALSE(0) ----

| |_timeAlignmentTimerDedicated : ---- sf1920(3) ---- |_physicalConfigDedicated :

|_cqi-ReportConfig :

| |_cqi-ReportModeAperiodic : ---- rm30(3) ---- | |_nomPDSCH-RS-EPRE-Offset : ---- 0x0(0) ---- | |_cqi-ReportPeriodic : | |_setup :

| |_cqi-PUCCH-ResourceIndex : ---- 0x0(0) ---- | |_cqi-pmi-ConfigIndex : ---- 0x12(18) ---- | |_cqi-FormatIndicatorPeriodic : | | |_widebandCQI : ---- (0)

| |_simultaneousAckNackAndCQI : ---- TRUE(1) ---- |_schedulingRequestConfig : |_setup :

|_sr-PUCCH-ResourceIndex : ---- 0x0(0) ---- |_sr-ConfigIndex : ---- 0x12(18) ---- 00010010 |_dsr-TransMax : ---- n64(4) ----

01 22 06 03 99 38 3c 8e 65 a0 3e 62 5a 7b b0 42 56 eb 9e da 18 0f b5 b3 84 a9 95 31 f0 2d 5c 81 af 42 43 17 e0 10 f2 d2 49 f2 d2 d1 4b 6b f3 4d 82 9e 85 c6 64 95 3f 3a b4 ec a4 69 52 1f 10 56 f4 05 8d 08 1f 2e 10 98 17 42 90 63 61 ec 13 57 d2 c7 e9 5d ea 3d b0 e2 44 4b b7 a1 a2 f6 4c fb d4 e5 c2 b2 70 a0 2a 1e 14 6f 66 bd c8 45 5f 61 14 69 d8 3f 04 b7 fb db 53 81 1f b9 c0 32 76 03 ea 06 d0 1d 87 51 41 c0 bc 88 83 01 3b 30 00 04 98 00 12 80

1.11 Security Mode Complete 信令解码如下:

-RRC-MSG : |_msg :

|_struUL-DCCH-Message :

MAC 主配置,分析见RRConnectionSetup 消物理信道配置,分析见

后台RNC信令分析资料剖析

目录 第1章CT工具的基本知识 (4) 1.1CT工具的配置 (4) 1.1.1服务器端配置 (4) 1.1.2客户端配置 (4) 1.1.3单机版使用 (6) 第2章信令分析说明 (7) 2.1 基本知识准备 (7) 2.1.1如何看业务信令 (7) 2.1.2流程中的几个重要概念 (9) 2.2 RRC建立过程的信令分析 (10) 2.2.1 RRC Connection Request信令综述 (10) 2.2.2 RRC Connection Request信令 (11) 2.2.3 Radio Link Setup信令 (13) 2.2.4 Radio Link Setup Response信令 (26) 2.2.5 Radio Link Setup Failure信令 (27) 2.2.6 RRC Connection Setup信令 (28) 2.2.7 Radio Link Restore Indication信令 (37) 2.2.8 RRC Connection SetupComplete信令 (37) 2.2.8 RRC建立过程中常见问题 (38) 2.3初始直传信令分析 (39) 2.3.1 InitialDirectTransfer信令分析 (41) 2.3.2 InitialUEMessage信令分析 (42) 2.3.2 CommonID信令分析 (42) 2.4鉴权过程(可选)信令分析 (43) 2.4.1 DirectTransfer信令分析(图中1) (46) 2.4.2 DownLinkDirectTransfer信令分析(图中2) (46) 2.4.3 UpLinkDirectTransfer信令分析(图中3) (47) 2.4.4 DirectTransfer信令分析(图中4) (47) 2.4.5 鉴权过程中常见问题 (48) 2.5安全模式信令分析 (48) 2.5.1 SecurityModeCommand(Iu口上,CN到RNC) (49) 2.5.2 SecurityModeCommand(Uu口上,RNC到UE) (53)

WCDMA信令分析(详细解释层三信令及涉及常用参数)-信令解码

呼叫信令详解(前后台) 呼叫流程信令图 起呼过程分四个阶段: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

移动主被叫及切换信令流程分析

1、主叫信令流程 移动用户做主叫时的信令过程从MS向BTS请求信道开始,到主叫用户TCH指配完成为止。一般来说,主叫经过几个大的阶段:接入阶段,鉴权加密阶段,TCH指配阶段,取被叫用户路由信息阶段。 接入阶段主要包括:信道请求,信道激活,信道激活响应,立即指配业务请求等几个步骤。经过这个阶段,手机和BTS BSC 建立了暂时固定的关系。 鉴权加密阶段主要包括:鉴权请求,鉴权响应,加密模式命令,加密模式完成,呼叫建立等几个步骤。经过这个阶段,主叫用户的身份已经得到了确认,网络认为主叫用户是一个合法用户允许继续处理该呼叫。 TCH指配阶段主要包括:指配命令,指配完成。经过这个阶段,主叫用户的话音信道已经确定,如果在后面被叫接续的过程中不能接通,主叫用户可以通过话音信道听到MSC的语音提示。 取被叫用户路由信息阶段主要包括:向HLR请求路由信息,HLR向VLR请求漫游号码,VLR回送被叫用户的漫游号码,HLR向MSC回送被叫用户的路由信息(MSRN)。MSC收到路由信息后,对被叫用户的路由信息进行分析,可以得到被叫用户的局向。然后进行话路接续。 主叫接入阶段、鉴权阶段主要信令: 当用户输入被叫号码完毕按下发射按纽后,手机(以下以MS代替)将进行一系列动作,首先MS将在随机接入信道(RACH )向BSS发送信道请求消息,以便申请一个专用信道(SDCCH ),BSC为其分配相应的信道成功后,在接入允许信道(AGCH)中通过立即分配消息通知MS为其分配的专用信道,随后MS将在为其分配的SDCCH上发送一个层三消息 ---CM业务请求消息,在该消息中CM业务类型为移动发起呼叫,该消息被BSS透明的传送至MSC,MSC收到CM业务请求消息后,通过处理接入请求消息通知VLR处理此次MS的接入业务请求,(同时,由于在BSC和MSC之间用到了SCCP有连接服务,为建立SCCP连接,MSC还将向BSC回连接确认消息),收到业务接入请求后,VLR将首先查看在数据库中该MS是否有鉴权三参组,如果有将直接向MSC下发鉴权命令,否则向相应的HLR/AUC请求鉴权参数,从HLR/AUC得到三参组,然后再向MSC下发鉴权命令。MSC收到VLR发送的鉴权命令后,通过BSS向MS下发鉴权请求,在该命令中含有鉴权参数,MS收到鉴权请求后,利

七号信令解码分析毕业论文

七号信令解码分析毕业论文 第一章引言 第一节开发背景 七号信令网是电信网的三大支撑网之一,是电信网的重要组成部分,其应用十分广泛。到目前为止,我国已经建立了由高级信令转接点(HSTP)、低级信令转接点(LSTP)和大量的信令点(SP)组成的三级七号信令网,七号信令网真正成为电信网的神经网和支撑网。为了保证七号信令网的正常高效运行,七号信令集中监测系统作为对七号信令网进行集中监测和管理的工具就显得格外重要。协议分析是七号信令监测平台中实时和历史数据分析的一个重要组成部分,它对获得完整的信令规程分析和实现网络故障精确定位具有重要意义,而无论什么样的信令消息,进入监测系统的第一个环节就是要被系统解码,消息解码的正确和完整与否对监测系统来说就显得非常重要。本文根据《中国国网NO.7信号方式技术规》对协议分析的要求,分析和介绍消息解码的原理和实现方法!由于条件所限我们无法从实际的网络环境中提取数据,因此,我们从后台数据库提取数据来模拟实际的网络环境,我认为完全可以通过数据库来存放从实际网络环境中得到的信令信息,然后通过我们的软件对消息进行解码分析,这并不影响我们的软件的使用围! 第二节软件实现的功能

本软件的名称是:《七号信令的消息分析(TUP部分)》。该软件能根据从数据库中所提取到的信令数据根据NO.7信号方式TUP技术规进行解码分析。通过该软件可以把TUP的所有的消息格式进行分析从而可以据此满足电信网络对七号信令协议测试和详细解码实现快速定位故障的需要。 第三节开发工具简介 为了实现以上功能我使用了VB作为我的开发工具。VB是微软公司开发的基于windows95/98/NT平台的32位程序设计开发平台,其最大优点是简单易学,使用它可以开发出高效,标准的Windows应用程序,它面向对象的特点,丰富的控件都为大型软件的开发提供了方便,但它的缺点也是显而易见的,正因为它的简单,在面向底层的实现方面有所欠缺,如指针,位操作等,但这不足以掩饰它是一个优秀的软件开发工具。 第四节本次课题所完成的工作 在本次毕业设计当中完成这个课题的是两个人,我的主要工作是对从数据库中提取到的数据进行解码分析,并利用伙伴给出的显示方法进行显示。

LTE信令流程图(端到端平台)

TDD-LTE 基本信令流程图

1 概述 本文主要针对TD-LTE端到端信令流程图进行分解,为端到端平台提供分析流程呈现依据。由于部分流程无S1口信令支撑,当前根据相关文档进行的绘制,后续具备条件后进行补充调整。

2 TDD-LTE网络结构概述 LTE的系统架构分成两部分,包括演进后的核心网EPC(MME/S-GW)和演进后的接入网E-UTRAN。演进后的系统仅存在分组交换域。 LTE接入网仅由演进后的节点B(evolved NodeB)组成,提供到UE的E-UTRA控制面与用户面的协议终止点。eNB之间通过X2接口进行连接,并且在需要通信的两个不同eNB之间总是会存在X2接口。LTE接入网与核心网之间通过S1接口进行连接,S1接口支持多—多联系方式。 与3G网络架构相比,接入网仅包括eNB一种逻辑节点,网络架构中节点数量减少,网络架构更加趋于扁平化。扁平化网络架构降低了呼叫建立时延以及用户数据的传输时延,也会降低OPEX与CAPEX。 由于eNB与MME/S-GW之间具有灵活的连接(S1-flex),UE在移动过程中仍然可以驻留在相同的MME/S-GW上,有助于减少接口信令交互数量以及MME/S-GW的处理负荷。当MME/S-GW与eNB之间的连接路径相当长或进行新的资源分配时,与UE连接的MME/S-GW 也可能会改变。 E-UTRAN

2.1 EPC 与E-UTRAN 功能划分 与3G 系统相比,由于重新定义了系统网络架构,核心网和接入网之间的功能划分也随之有所变化,需要重新明确以适应新的架构和LTE 的系统需求。针对LTE 的系统架构,网络功能划分如下图: eNodeB 功能: 1) 无线资源管理相关的功能,包括无线承载控制、接纳控制、连接移动 性管理、上/下行动态资源分配/调度等; 2) IP 头压缩与用户数据流加密; 3) UE 附着时的MME 选择; 4) 提供到S-GW 的用户面数据的路由; 5) 寻呼消息的调度与传输; 6) 系统广播信息的调度与传输; 7) 测量与测量报告的配置。 MME 功能: 1) 寻呼消息分发,MME 负责将寻呼消息按照一定的原则分发到相关的 eNB ; 2) 安全控制; E-UTRAN

TDLTE信令流程及信令解码详解

TD-LTE信令流程及信令解码 本文主要就PS业务建立流程和LTE系统内切换的信令及信令解码进行重点IE分析,并加以标注,所有信令为eNB侧跟踪的信令。 PS业务建立流程: 1.1RRC Connection Request UE上行发送一条RRC Connection Request消息给eNB,请求建立一条RRC连 接,该消息携带主要IE有: -ue-Identity :初始的UE标识。如果上层提供S-TMSI,侧该值为S-TMSI; 否则从0…240-1中抽取一个随机值,设置为ue-Identity。 -establishmentCause:建立原因。该原因值有emergency, highPriorityAccess, mt-Access, mo-Signalling, mo-Data, spare3, spare2, spare1。其中“mt”代表移动终端,“mo”代表移动始端。 信令解码如下: -RRC-MSG : |_msg : |_struUL-CCCH-Message : |_struUL-CCCH-Message : |_message : |_c1 : |_rrcConnectionRequest : |_criticalExtensions : |_rrcConnectionRequest-r8 : |_ue-Identity : |_establishmentCause : ---- highPriorityAccess(1) |_spare : ---- '0'B(00 ) 04 53 14 97 b7 8c 32 1.2RRC Connection Setup UE初始标识,此处因为上层没有提供S-TMSI,所以为随机值。 建立原因,此处 highPriorityAcces s指的是AC11~AC15

TDLTE信令流程及信令解码

T D L T E信令流程及信令 解码 Document number:BGCG-0857-BTDO-0089-2022

TD-LTE信令流程及信令解码 ()

本文主要就PS业务建立流程和LTE系统内切换的信令及信令解码进行重点IE分析,并加以标注。所有信令为eNB侧跟踪的信令。 1.PS业务建立流程: 1.1RRC Connection Request UE上行发送一条RRC Connection Request消息给eNB,请求建立一条RRC连接,该消息携带主要IE有: -ue-Identity :初始的UE标识。如果上层提供S-TMSI,侧该值为S-TMSI;否则从0…240-1中抽取一个随机值,设置为ue-Identity。

establishmentCause :建立原因。该原因值有emergency---拨打紧急号码, HighPriorityAccess---高优先级接入,mt-access--被叫接入,mo-Signalling--发送信令时,mo-Data---发送数据时,DelayTolerantAccess-v1020---R10中新增原因,延迟容忍接入。其中“mt”代表移动终端,“mo”代表移动始端。 信令解码如下: -RRC-MSG : |_msg : |_struUL-CCCH-Message : |_struUL-CCCH-Message : |_message : |_c1 : |_rrcConnectionRequest : |_criticalExtensions : |_rrcConnectionRequest-r8 : |_ue-Identity : | |_randomValue : ----'00'B(31 49 7B 78 C3 ) ---- |_establishmentCause : ---- highPriorityAccess(1) |_spare : ---- '0'B(00 ) 04 53 14 97 b7 8c 32 UE 初始标识,此处 因为上层没有提供 S-TMSI,所以为随机 建立原因,此处highPriorityAc

非常详细的LTE信令流程

LTE信令流程

目录 第一章协议层与概念 (5) 1.1控制面与用户面 (5) 1.2接口与协议 (5) 1.2.1NAS协议(非接入层协议) (7) 1.2.2RRC层(无线资源控制层) (7) 1.2.3PDCP层(分组数据汇聚协议层) (8) 1.2.4RLC层(无线链路控制层) (8) 1.2.5MAC层(媒体接入层) (9) 1.2.6PHY层(物理层) (10) 1.3空闲态和连接态 (12) 1.4网络标识 (13) 1.5承载概念 (14) 第二章主要信令流程 (16) 2.1 开机附着流程 (16) 2.2随机接入流程 (19) 2.3 UE发起的service request流程 (23) 2.4寻呼流程 (26) 2.5切换流程 (27) 2.5.1 切换的含义及目的 (27) 2.5.2 切换发生的过程 (28) 2.5.3 站内切换 (28) 2.5.4 X2切换流程 (30) 2.5.5 S1切换流程 (32) 2.5.6 异系统切换简介 (34) 2.6 CSFB流程 (35) 2.6.1 CSFB主叫流程 (36) 2.6.2 CSFB被叫流程 (37) 2.6.3 紧急呼叫流程 (39) 2.7 TAU流程 (40) 2.7.1 空闲态不设置“ACTIVE”的TAU流程 (41)

2.7.2 空闲态设置“ACTIVE”的TAU流程 (43) 2.7.3 连接态TAU流程 (45) 2.8专用承载流程 (46) 2.8.1 专用承载建立流程 (46) 2.8.2 专用承载修改流程 (48) 2.8.3 专用承载释放流程 (50) 2.9去附着流程 (52) 2.9.1 关机去附着流程 (52) 2.9.1 非关机去附着流程 (53) 2.10 小区搜索、选择和重选 (55) 2.10.1 小区搜索流程 (55) 2.10.1 小区选择流程 (56) 2.10.3 小区重选流程 (57) 第三章异常信令流程 (60) 3.1 附着异常流程 (61) 3.1.1 RRC连接失败 (61) 3.1.2 核心网拒绝 (62) 3.1.3 eNB未等到Initial context setup request消息 (63) 3.1.4 RRC重配消息丢失或eNB内部配置UE的安全参数失败 (64) 3.2 ServiceRequest异常流程 (65) 3.2.1 核心网拒绝 (65) 3.2.2 eNB建立承载失败 (66) 3.3 承载异常流程 (68) 3.3.1核心网拒绝 (68) 3.3.2 eNB本地建立失败(核心网主动发起的建立) (68) 3.3.3 eNB未等到RRC重配完成消息,回复失败 (69) 3.3.4 UE NAS层拒绝 (70) 3.3.5上行直传NAS消息丢失 (71) 第四章系统消息解析 (72) 4.1 系统消息 (73) 4.2 系统消息解析 (74) 4.2.1 MIB (Master Information Block)解析 (74) 4.2.2 SIB1 (System Information Block Type1)解析 (75) 4.2.3 SystemInformation消息 (77) 第五章信令案例解析 (83) 5.1实测案例流程 (84)

编解码流程

目录 1 编解码流程 (2) 1.1 编码流程 (2) 1.2 PES、TS结构 (3) PES结构分析(ES打包成PES) (3) TS结构:(PES经复用器打包成TS): (4) 2 解码流程 (5) 2.1 获取TS中的PAT (5) 2.2 获取TS中的PMT (6) 2.3 分流过滤 (6) 2.4 解码 (7) 3 DVB和ATSC制式 (7) 3.1 DVB和ATSC的区别 (7) 3.2 DVB和ATSC的SI (8)

1编解码流程 1.1编码流程 图1-1 ES:原始码流,包含视频、音频或数据的连续码流。 PES:打包生成的基本码流,是将基本的码流ES流根据需要分成长度不等的数据包,并加上包头就形成了打包的基本码流PES流,可以是不连续的。 TS:传输流,是由固定长度为188字节的包组成,含有独立时基的一个或多个节目,适用于误码较多的环境。 PS:节目流. TS流与PS流的区别在于TS流的包结构是固定长度的,而PS 流的包结构是可变长度的。在信道环境较为恶劣,传输误码较高时,一般采用TS码流;而在信道环境较好,传输误码较低时,一般采用PS码流。TS码流具有较强的抵抗传输误码的能力。

最后经过64QAM调制及上变频形成射频信号在HFC网中传输,在用户终端经解码恢复模拟音视频信号。 1.2PES、TS结构 PES结构分析(ES打包成PES) ES是直接从编码器出来的数据流,可以是编码过的视频数据流,音频数据流,或其他编码数据流的统称。每个ES都由若干个存取单元(AU)组成,每个AU实际上是编码数据流的显示单元,即相当于解码的1幅视频图像或1个音频帧的取样。 ES流经过PES打包器之后,被转换成PES包。PES包由包头和payload组成。 打包时,加入显示时间标签(Presentation Time-Stamp,PTS),解码时间标签(Decoding Time-Stamp,DTS)及段内信息类型等标志信

LTE信令流程之开机附着、去附着流程分析

LTE信令流程之开机附着、去附着流程分析 开机附着流程 开机附着流程说明: ?N0010处在RRC_IDLE态的UE进行Attach过程,发起随机接入过程,即MSG1消息; ?N0020eNB检测到MSG1消息后向UE发送随机接入响应消息,即MSG2消息;

?N0030UE收到随机接入响应后,根据MSG2的TA调整上行发送时机,向eNB发送RRCConnectionRequest消息申请建立RRC连接; ?N0040eNB向UE发送RRCConnectionSetup消息,包含建立S RB1信令承载信息和无线资源配置信息; ?N0050 UE完成SRB1信令承载和无线资源配置,向eNB发送RRC ConnectionSetupComplete消息,包含NAS层Attach request信息; ?N0060eNB选择MME,向MME发送INITIAL UE MESSAGE 消息,包含NAS层Attach request消息; ?N0070 MME向eNB发送INITIAL CONTEXT SETUP REQUES T消息,包含NAS层Attach Accept消息; ?N0080eNB接收到INITIAL CONTEXT SETUP REQUEST消息,如果不包含UE能力信息,则eNB向UE发送UECapabilityEnquiry消息,查询UE能力; ?N0090 UE向eNB发送UECapabilityInformation消息,报告UE能力信息; ?N0100 eNB向MME发送UE CAPABILITY INFO INDICATION消息,更新MME的UE能力信息; ?N0110 eNB根据INITIAL CONTEXT SETUP REQUEST消息中UE支持的安全信息,向UE发送SecurityModeCommand消息,进行安全激活; ?N0120 UE向eNB发送SecurityModeComplete消息,表示安全激活完成; ?N0130 eNB根据INITIAL CONTEXT SETUP REQUEST消息中的ERAB 建立信息,向UE发送RRCConnectionReconfiguration消息进行UE资源重配,包括重配SRB1信令承载信息和无线资源配置,建立SRB2、DRB(包括默认承载)等; ?N0140 UE向eNB发送RRCConnectionReconfigurationComplete消息,表示无线资源配置完成; ?N0150 eNB向MME发送INITIAL CONTEXT SETUP RESPONSE响应消息,表明UE上下文建立完成; ?N0160 UE向eNB发送ULInformationTransfer消息,包含NAS层Attach C omplete、Activate default EPS bearer context accept消息;

GSM信令分析及流程详解大全

Layer 3信令分析及流程详解汇编Layer 3信令是看网络运行情况的信息层,从第三层可以看到网络的各种动作:如:呼叫流程、拥塞、用户忙、位置更新等,并且可以对路测中的各种问题如掉话、切换失败等网络事件的原因进行准确的分析。 系统信息一般有8个类型,分别是1、2、3、4、5、6、7、8,Type 1~4只出现在待机状态下,Type 5~6只出现在通话状态下,明白这点,对以后的分析至关重要。其中2中含有:2、2bis、2ter, 5中含有5、5bis、5ter,所以总共有12种系统信息,系统信息1仅用于跳频,所以称为选择项。其中1、2、3、4、 2bis、 2ter 、7、8都在BCCH上发送,由IDLE模式下的移动台接收。5、5bis、5ter、6在SACCH上发送,由ACTIVE模式下的移动台接收。一般来说所有系统信息在连续的8个51复帧中发送完,如下图示: 上图中的TC表示复帧序列号,可以看出,当TC=4、5时,发送的内容是可选的,其它是固定的。 TC=0固定发送跳频信息,当出现上图示的1(3)时,表示跳频时发类型1,不跳频时发类型3 当类型4中发送的关于小区重选信息不够完整时,由类型7、8补充。且在TC=7、3时发送(上图示) 对于类型5、6在下行的SACCH上发送,并没有复帧规范,除非切换完成后要立即发送类型5、6。 1、System Information Type1

说明:系统信息类型 1 (频率信息) 此类型仅用于跳频时,发送内容为: 第一、小区信道描述。用于通知移动,小区采用的频带与可以供跳频用的频点。对于GSM900与GSM1800采用的格式是不同的。对于GSM900: 有一个BIT MAP 0(比特位图)用于描述两方面信息,分别为: CA-NO,取值分别为:0、1、2,代表,GSM900、GSM1800、GSM1900。 CA-ARFCN,采用的有效射频频点,当为GSM900,将有一个相应于124个频点的124位图,当某个频点被采用时,相应的比特位被置为1,否则将被置为0. 对于GSM1800情况点不同。由于频点太多,不用位图,而用别的编码方式,FORMAD-IND=?来描述编码方式,后面跟一串编码比特来表示。 第二、RACH控制参数,描述的两个数据为;ACC、EC,ACC称为接入控制等级,分为0-9与 11-15,0-9表示普通级,所有移动台被定义为0-9,11-15为优先级,10表示EC,如果此位取0,表示所有移动台允许进行紧急呼叫,取1时,只有11-15优先级的移动台可以进行紧急呼叫。 CB——小区禁止标志,用一个比特表示。

TDLTE信令流程及信令解码比超详细还详细

TD-LTE信令流程及信令解码 (2013.03) 本文主要就PS业务建立流程和LTE系统内切换的信令及信令解码进行重点IE分析,并加以标注。所有信令为eNB侧跟踪的信令。 1.PS业务建立流程: 1.1RRC Connection Request UE上行发送一条RRC Connection Request消息给eNB,请求建立一条RRC连接,该消息携带主要IE有: -ue-Identity :初始的UE标识。如果上层提供S-TMSI,侧该值为S-TMSI;否则从0…240-1中抽取一个随机值,设置为ue-Identity。 -establishmentCause :建立原因。该原因值有emergency, highPriorityAccess, mt-Access, mo-Signalling, mo-Data, spare3, spare2, spare1。其中“mt”代表移动终端,“mo”代表 移动始端。 信令解码如下: -RRC-MSG : |_msg : |_struUL-CCCH-Message : |_struUL-CCCH-Message : |_message : |_c1 : |_rrcConnectionRequest : |_criticalExtensions : |_rrcConnectionRequest-r8 : |_ue-Identity : |_establishmentCause : ---- highPriorityAccess(1) UE初始标识,此处因为上层没有提供S-TMSI,所以为随机值。 建立原因,此处 highPriorityAccess 指的是AC11~AC15

信令流程与GT翻译对应关系详解

信令流程与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 识别号。

层3信令分析及详解

Layer 3信令分析及流程详解汇编

Layer 3信令是看网络运行情况的信息层,从第三层可以看到网络的各种动作:如:呼叫流程、拥塞、用户忙、位置更新等,并且可以对路测中的各种问题如掉话、切换失败等网络事件的原因进行准确的分析。 系统信息一般有8个类型,分别是1、2、3、4、5、6、7、8,Type 1~4只出现在待机状态下,Type 5~6只出现在通话状态下,明白这点,对以后的分析至关重要。其中2中含有:2、2bis、2ter,5中含有5、5bis、5ter,所以总共有12种系统信息,系统信息1仅用于跳频,所以称为选择项。其中1、2、3、4、2bis、2ter 、7、8都在BCCH上发送,由IDLE模式下的移动台接收。5、5bis、5ter、6在SACCH上发送,由ACTIVE模式下的移动台接收。一般来说所有系统信息在连续的8个51复帧中发送完,如下图示: 上图中的TC表示复帧序列号,可以看出,当TC=4、5时,发送的内容是可选的,其它是固定的。 TC=0固定发送跳频信息,当出现上图示的1(3)时,表示跳频时发类型1,不跳频时发类型3 当类型4中发送的关于小区重选信息不够完整时,由类型7、8补充。且在TC=7、3时发送(上图示) 对于类型5、6在下行的SACCH上发送,并没有复帧规范,除非切换完成后要立即发送类型5、6。 1、System Information Type1

说明:系统信息类型1 (频率信息) 此类型仅用于跳频时,发送内容为: 第一、小区信道描述。用于通知移动,小区采用的频带与可以供跳频用的频点。对于GSM900与GSM1800采用的格式是不同的。对于GSM900: 有一个BIT MAP 0(比特位图)用于描述两方面信息,分别为: CA-NO,取值分别为:0、1、2,代表,GSM900、GSM1800、GSM1900。 CA-ARFCN,采用的有效射频频点,当为GSM900,将有一个相应于124个频点的124位图,当某个频点被采用时,相应的比特位被置为1,否则将被置为0. 对于GSM1800情况点不同。由于频点太多,不用位图,而用别的编码方式,FORMAD-IND=?来描述编码方式,后面跟一串编码比特来表示。 第二、RACH控制参数,描述的两个数据为;ACC、EC,ACC称为接入控制等级,分为0-9与11-15,0-9表示普通级,所有移动台被定义为0-9,11-15为优先级,10表示EC,如果此位取0,表示所有移动台允许进行紧急呼叫,取1时,只有11-15优先级的移动台可以进行紧急呼叫。 CB——小区禁止标志,用一个比特表示。

TD-LTE信令流程及信令解码

TD-LTE信令流程及信令解码 TD-LT信令流程及信令解码 TD-LTE信令流程及信令解码 ,2013.03, 第1页共81页 TD-LT信令流程及信令解码 本文主要就PS业务建立流程和LTE系统内切换的信令及信令解码进行重点IE 分析,并加以标注。所有信令为eNB侧跟踪的信令。 1. PS业务建立流程, 1.1 RRC Connection Request UE上行发送一条RRC Connection Request消息给eNB,请求建立一条RRC连接,该消息携带主要IE有,

- ue-Identity :初始的UE标识。如果上层提供S-TMSI,侧该值为S-TMSI,否则从 第2页共81页 TD-LT信令流程及信令解码 400…2-1中抽取一个随机值,设置为ue-Identity 。 - establishmentCause :建立原因。该原因值有emergency, highPriorityAccess, mt-Access, mo-Signalling, mo-Data, spare3, spare2, spare1。其中“mt”代表移动终 端,“mo”代表移动始端。 信令解码如下, -RRC-MSG : |_msg : |_struUL-CCCH-Message : |_struUL-CCCH-Message : |_message : |_c1 : UE初始标识,此处因为 |_rrcConnectionRequest : |_criticalExtensions : 上层没有提供S-TMSI,所 |_rrcConnectionRequest-r8 : |_ue-Identity : 以为随机值。 | |_randomValue : ---- '0011000101001001011110110111100011000011'B(31 49 7B 78 C3 ) ----

信令流程详解

1 信令分析 在分析问题时,请参照正确的流程,逐步检查到底哪一条消息没有收到,并且分析上一条消息里面携带的内容,从而定位原因所在。 1.1 主被叫呼叫建立流程 1.1.1正常信令 在分析接入问题时,请参照上图所示正确的流程,逐步检查到底哪一条消息没有收到,且分析上一条消息里面携带的内容,从而定位原因所在 【注】Abis-BTS setup消息里面,携带了接入的小区、扇区、walsh码、频点。 关键点1:BSC向MSC发送CM Service Request后,是否收到Assignment Request。如果没有收到MSC发的Assignment Request,等到6s后定时器超时,基站会给手机发送release order.这种情况是A1接口失败。 关键点2:BTS是否向BSC发送Abis-BTS Setup Ack。Abis如有问题,如误码高、信令链路带宽不足等,将会体现为Abis无法建链成功,话统原因“指配资源失败” 关键点3:是否发送ECAM(扩展信道指配消息)消息。如Abis正常建链,但却没有发

送ECAM消息,在话统里面会体现为“指配资源失败”,可能原因是walsh、CE、power不足。 关键点4:是否在F-DSCH发送order message,如没有收到,说明捕获业务信道前导帧失败。 关键点5:是否发送Assignment complete。如发送表明呼叫建立成功。如没有收到,在话统里面体现为“信令交互失败”。 被叫流程与主叫几乎完全一致,被叫中的Paging Response相当于主叫的origination message。 1.1.2典型异常信令 1、A1接口失败。 2、传输误码率高导致指配资源失败

TD-LTE呼叫信令流程分析

TD-LTE呼叫信令流程分析2011年评审通过

1文档介绍 1.1 文档目的 预期的读者是ENODEB软件工程师、软件测试工程师以及网规网优人员。 1.2 文档范围 本文分析了SERVICE REQUEST、专用承载建立、修改和释放过程中涉及的各条消息以及每条消息中包含的IE。 1.3 参考资料 【1】LTE_call_processing_entity_msg_flow_zengzhaohui.vsd 【2】3GPP TS 36.413 S1 Application Protocol (S1AP)(Release 9) 【3】3GPP TS 24.301 Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS) (Release 9) 【4】3GPP TS 36.331 Radio Resource Control (RRC) (Release 9) 1.4 术语和缩略语定义 略。

2公用子流程 2.1.1RRC连接建立 2.1.1.1 RRC连接建立相关流程 图 2-1: RRC连接的成功建立流程 图2-2: RRC连接建立,网络侧发起拒绝 2.1.1.2 关键消息 RRCConnectionRequest RRCConnectionRequest消息用于请求建立RRC连接。该消息的一些具体信息为: 信令承载: SRB0 RLC-SAP:TM 逻辑信道:CCCH 消息的主要IE:第四节所附EXCEL文档 RRCConnectionSetup RRCConnectionSetup消息用于建立SRB1。该消息的一些具体信息为: 信令承载: SRB0 RLC-SAP:TM 逻辑信道:CCCH 消息的主要IE:第四节所附EXCEL文档 RRCConnectionSetupComplete RRCConnectionSetupComplete消息表示成功建立RRC连接。该消息的一些具体信息为:

GSM信令分析及流程详解大全

Layer 3信令分析及流程详解 汇编 Layer 3信令是看网络运行情况的信息层,从第三层可以看到网络的各种动作:如:呼叫流程、拥塞、用户忙、位置更新等,并且可以对路测中的各种问题如掉话、切换失败等网络事件的原因进行准确的分析。 系统信息一般有8个类型,分别是1、2、3、4、5、6、7、8,Type 1~4只出现在待机状态下,Type 5~6只出现在通话状态下,明白这点,对以后的分析至关重要。其中2中含有:2、2bis、2ter, 5中含有5、5bis、5ter,所以总共有12种系统信息,系统信息1仅用于跳频,所以称为选择项。其中1、2、3、4、 2bis、 2ter 、7、8都在BCCH上发送,由IDLE模式下的移动台接收。5、5bis、5ter、6在SACCH上发送,由ACTIVE模式下的移动台接收。一般来说所有系统信息在连续的8个51复帧中发送完,如下图示:上图中的TC表示复帧序列号,可以看出,当TC=4、5时,发送的内容是可选的,其它是固定的。 TC=0固定发送跳频信息,当出现上图示的1(3)时,表示跳频时发类型1,不跳频时发类型3 当类型4中发送的关于小区重选信息不够完整时,由类型7、8补充。且在TC=7、3时发送(上图示) 对于类型5、6在下行的SACCH上发送,并没有复帧规范,除非切换完成后要立即发送类型5、6。 1、System Information Type1 说明:系统信息类型 1 (频率信息) 此类型仅用于跳频时,发送内容为: 第一、小区信道描述。用于通知移动,小区采用的频带与可以供跳频用的频点。对于GSM900与GSM1800采用的格式是不同的。对于GSM900: 有一个BIT MAP 0(比特位图)用于描述两方面信息,分别为: CA-NO,取值分别为:0、1、2,代表,GSM900、GSM1800、GSM1900。 CA-ARFCN,采用的有效射频频点,当为GSM900,将有一个相应于124个频点的124位图,当某个频点被采用时,相应的比特位被置为1,否则将被置为0.

相关主题
相关文档 最新文档