Q1. "Filter in front of LNA" vs "LNA in front of filter"
A1. "LNA in front of filter" (w/ proper frequency response) provides better RF performance.
Q2. PA linearity index?
Q3. Spectrum Analyzer : Resolution BW vs Video BW
A3. Resolution BW : frequency axis grid
Video BW : displayed spectrum is low-pass filtered.
Q4. Btwn TDD and FDD, which requires higher quality power supply? why?
(same Fc, BW, 64QAM and peak power)
A4. FDD. Higher power supply helps inter band seperation.
Source https://www.itsfun.com.tw/BPDU/wiki-8372865-1834445
網橋協定資料單元(Bridge Protocol Data Unit)。是一種生成樹協定問候封包，它以可配置的間隔發出，用來在網路的網橋間進行信息交換。
當一個網橋開始變為活動時，它的每個連線埠都是每2s(使用缺省定時值時)傳送一個BPDU。然而，如果一個連線埠收到另外一個網橋傳送過來的BPDU，而這個BPDU比它正在傳送的BPDU更優，則在地連線埠會停止傳送BPDU。如果在一段時間(缺省為20s)後它不再接收到鄰居的更優的BPDU，則在地連線埠會再次傳送BPDU。
BPDU是網橋協定資料單元(Bridge Protocol Data Unit)的英文首字母縮寫。
協定ID:該值總為0。
版本號:STP的版本(為IEEE 802.1d時值為0)。
報文類型:BPDU類型(配置BPDU=0，TCN BPDU=80)。
標記域:LSB(最低有效位)=TCN標志;MSB(最高有效位)=TCA標志。
根網橋ID:根信息由2位元組優先權和6位元組ID組成。這個信息組合標明已經被選定為根網橋的設備標識。
根路徑成本:路徑成本為到達根網橋交換機的STP開銷。表明這個BPDU從根網橋傳輸了多遠，成本是多少。這個欄位的值用來決定哪些連線埠將進行轉發，哪些連線埠將被阻斷。
傳送網路橋ID:傳送該BPDU的網橋信息。由網橋的優先權和網橋ID組成。
連線埠ID:傳送該BPDU的網橋連線埠ID。
計時器:計時器用于說明生成樹用多長時間完成它的每項功能。這些功能包括報文老化時間、最大老化時間、訪問時間和轉發延遲。
最大老化時間:根網橋傳送BPDU後的秒數，每經過一個網橋都會增加1，所以它的本質是到達根網橋的跳計數。
訪問時間:根網橋連續傳送BPDU的時間間隔。
轉發延遲:網橋在監聽學習狀態所停留的時間。
BPDU究竟是如何工作的呢?
這得從網橋說起。網橋有三種典型的方式:透明橋、源路由橋與源路由透明橋。
網橋典型地連線兩個用同樣介質存取控製方法的網段，IEEE 802.1d規範(此規範是為所有的802介質存取方法開發的)定義了透明橋。源路由橋是由IBM公司為它的令牌環網路開發的;而源路由透明橋則是透明橋和源路由橋的組合。橋兩邊的網段分屬于不同的沖突域，但卻屬于同一個廣播域。
在一個橋接的區域網路裏，為了增強可靠性，必然要建立一個冗餘的路徑，網段會用冗餘的網橋連線。但是，在一個透明橋橋接的網路裏，存在冗餘的路徑就能建立一個橋回路，橋回路對于一個區域網路是致命的。
生成樹協定是一種橋嵌套協定，在IEEE 802.1d規範裏定義，可以用來消除橋回路。它的工作原理是這樣的:生成樹協定定義了一個封包，叫做橋協定資料單元BPDU(Bridge Protocol Data Unit)。網橋用BPDU來相互通信，並用BPDU的相關機能來動態選擇根橋和備份橋。但是因為從中心橋到任何網段隻有一個路徑存在，所以橋回路被消除。
在一個生成樹環境裏，橋不會立即開始轉發功能，它們必須首先選擇一個橋為根橋，然後建立一個指定路徑。在一個網路裏邊擁有最低橋ID的將變成一個根橋，全部的生成樹網路裏面隻有一個根橋。根橋的主要職責是定期傳送配置信息，然後這種配置信息將會被所有的指定橋傳送。這在生成樹網路裏面是一種機製，一旦網路結構發生變化，網路狀態將會重新配置。
當選定根橋之後，在轉發封包之前，它們必須決定每一個網段的指定橋，運用生成樹的這種演算法，根橋每隔2秒鍾從它所有的連線埠傳送BPDU包，BPDU包被所有的橋從它們的根連線埠復製過來，根連線埠是接根橋的那些橋連線埠。BPDU包括的信息叫做連線埠的COST，網路管理員分配連線埠的COST到所有的橋連線埠，當根橋傳送BPDU的時候，根橋設定它的連線埠值為零。然後沿著這條路徑，下一個橋增加它的配置連線埠COST為一個值，這個值是它接收和轉發封包到下一個網段的值。這樣每一個橋都增加它的連線埠的COST值為它所接收的BPDU的包的COST值，所有的橋都檢測它們的連線埠的COST值，擁有最低連線埠的COST值的橋就變為了指定的橋。擁有比較高連線埠COST值的橋置它的連線埠進入阻塞狀態，變為了備份橋。在阻塞狀態，一個橋停止了轉發，但是它會繼續接收和處理BPDU封包。
Source http://smalleaf.blogspot.com/2011/10/switch-bpdu-guard.html
防止私接Switch的利器 - BPDU GUARD
今天客戶問我一個問題:
Source https://a46087.pixnet.net/blog/post/32217254
======================================================================
|
網孔底 |
Hub |
NB / Win10 / WiFi/Ethernet network bridge
by following https://superuser.com/questions/1319833/use-wifi-and-ethernet-simultaneously-on-windows-10 |
|
PC / Linux / Ethernet |
Source https://stackoverflow.com/questions/942273/what-is-the-ideal-fastest-way-to-communicate-between-kernel-and-user-space
mmap
system calls
ioctls
/proc & /sys
netlink
Source https://magicjackting.pixnet.net/blog/post/113860339
Reentrant vs Thread-safe
Reentrancy 和 thread-safty 是兩個容易被搞混了的觀念. 其中最嚴重的是誤以為 reentrant function 必定是 thread-safe 或者相反以為 thread-safe function 必為 reentrant, stackoverflow 網站上的答覆甚至同時出現二種答案的現象.
首先來看 reentrancy: 字面上的意思是可重入. Reentrancy 原先是討論單一執行緒環境下 (即沒有使用多工作業系統時) 的主程式和中斷服務程式 (ISR) 之間共用函數的問題. 當然現在多核心的 CPU 盛行, 討論範圍也必需擴充至多執行緒的情況. 重點是它討論的主體是: 在 ISR 中使用的函數 (不論是自己寫的或者是函數庫提供的) 是否會引發錯誤結果. 主要的達成條件是二者 (ISR 和非 ISR) 的共用函數中不使用靜態變數或全域變數 (意即只用區域變數). 一般是撰寫驅動程式 (device driver) 或者是寫 embedded system 的人會遇到這個問題.
再來是 thread-safety: 字面上的意思是執行緒 (線程) 安全. Thread-safe 一開始就針對多執行緒的環境 (CPU 可能單核也可能是多核), 討論的是某一段程式碼在多執行緒環境中如何保持資料的一致性 (及完整性), 使不致於因為執行緒的切換而產生不一致 (及不完整) 或錯誤的結果. 所以是程式中有運用到多執行緒的大型應用系統的程式人員會比較常遇到這類問題. 問題的產生點一般出現在對某一共用變數 (或資源) 進行 read-modify-write (或者類似的動作(註一)) 時, 還沒來得及完成整個動作, 就被其他的執行緒插斷, 並且該執行緒也一樣對這個共用變數 (或資源) 進行 read-modify-write (或者類似的動作). 例如Thread1 和 Thread2 之間我們需要一個作為計數器的共用變數:
'\r'是回車，前者使游標到行首，（carriage return）ASCII碼（0x0D）
'\n'是換行，後者使游標下移一格，（line feed）ASCII碼(0xoA)Source: https://www.trustonic.com/technical-articles/comparing-the-tee-to-integrated-hsms/
As more and more devices become connected so the need for ever greater security and protection of critical assets increases. Traditionally such support has been provided by a Hardware Security Module (HSM) but over the last decade the use of Trusted Execution Environments (TEE) has grown significantly. This article aims to provide the reader with an understanding of the difference between these two solutions and their suitability for different scenarios.
Generically, a HSM provides key management and cryptographic functionality for other applications.
A TEE also provides this functionality, along with enabling application (or security focused parts of applications) to execute inside its isolation environment.
For example, in modern Android mobile devices, the TEE is already unknowingly used every day, by millions of people as an HSM equivalent, through the use of a Trusted Application (TA) providing the Android KeyMaster functionality.
Regular Execution Environment (REE) is the term in the TEE community for everything in a device that is outside a particular TEE. Technically, from a particular TEEs point of view, all components that are outside of its security boundary live in the REE. Having said that, for simplification of the big picture, a device with multiple TEEs, SIMs, HSMs or other high trust components, may have those separated out from the REE. The REE houses the Regular OS, which in combination with the rest of that execution environment, does not have sufficient security to meet a task needed by the device.
For more background on terminology like TEE and REE please have a look in “What is a TEE?”
For more information on the ARM TrustZone hardware security behind the TEE have a look in “What is a TrustZone?”
In compact devices with integrated HSM, the software architecture looks something like this:
The HSM provides Cryptographic Services to your security focused task.
The “Secure” task in the REE has data. The HSM can receive that data and encrypt or decrypt that data, before handing it back to the issuer task in the REE.
Here is how we support HSM functionality in a TEE enabled device today:
In an Android device, the above HSM will typically be replaced by a TA, within the TEE, implementing Keymaster functionality and an Android specific REE stack rather than OpenSSL/PKCS#11.
In the above case, with a simpler Regular OS as might be found in an Engine Control Unit (ECU), a generic TA has been specifically written to provide the functionality of a typical HSM.
A TEE need not be used as a fixed purpose service provider like an HSM, it can also host the tasks directly.
Here we move the task into the TEE and manipulation of the unencrypted data can occur, in a place inaccessible to activity in the REE.
As an example of what we gain:
Some HSMs can load code to execute through proprietary extensions, but a GlobalPlatform compliant TEE uses standardised interfaces, enabling tasks developed for one TEE, to execute on another. Such tasks, executing in the TEE, are called “Trusted Applications”.
HSM’s cannot directly protect the I/O ports providing sensor data, or controlling actuators, from software attacks in, for example, the REE of the ECU of a vehicle.
Unlike an HSM, on a correctly designed System-On-Chip (SoC) a TEE can also interface to peripherals. This enables the creation of a secure task, housed safely inside the TEE, that can be used to substantially enhance the critical tasks’ security.
Well, consider an example, from the automotive industry, of a fuel throttle. If the throttles’ I/O control port on the ECU is exposed in the REE software then it does not matter how much security the REE “Secure” task use of the HSM brings; you would not be using an HSM if you had high confidence in the security of the REE itself, and so you cannot have confidence that the software in the REE cannot be attacked.
If the REE is open to attack, that means that attacked REE software can potentially gain unauthorised access to that I/O port, no matter how good the HSM is.
In the TEE (like in an HSM), we do not have the generic load of software tasks unrelated to security. A task in the TEE can interface to hardware control ports without risk of other software making unauthorised access.
If I only have an HSM in the above example, then all I can do is protect the data traffic to a device, not the decision making in the device. With a TEE, I can do both.
As we have seen above, one issue with the use of an HSM is the exposure of data communications before any encryption has occurred.
Fundamentally, device integrated HSMs might go as far as to use on-SoC hardware methods to protect their keys from extraction that are stronger than those of a TEE. However, the method to transfer data to the HSM for protection by those keys is no more strongly protected, than that used by a TEE and can be far weaker.
Consider the following PCB-attached HSM in comparison to a typical TEE which will be using a stacked die (Package on a Package) to protect its much higher speed traffic:
Stronger TEEs do not even use external RAM, as shown above, but can use on-SoC RAM instead.
In this case, the benefit of using a TEE to provide traditional HSM functionality is a significant reduction in the exposure of unprotected data and therefore an enhancement of the overall security for the platform.
Ultimately, if you are concerned about key extraction, it is advised that designs keep the key batch size small, whether using a TEE or an HSM.
It is worth noting that in the EVITA standards, some HSM types reside on the same SoC as the REE, but in those cases their hardware protection methods are typically the same as a TEE (see the EVITA HSM levels).
In fast moving new innovation areas, such as connected vehicles and robotics, as well as consumer electronics devices, a TEE provides a cost effective and future proofed alternative to using an HSM.
In addition to the potential of providing typical HSM functionality, a GlobalPlatform compliant TEE can also protect the critical tasks directly and has standardised methods for enabling over-the-air updating of critical systems.
Fundamentally, a typical HSM is an attack-resistant cryptographic device designed to perform a specific set of cryptographic functions by the HSM designer. It provides the confidence of non-interference inside the scope defined by the relevant protection profile. A standardised TEE can do the same, and significantly more without the need to add additional hardware. As the TEE resides on the existing SoC integrated MMUs and TrustZone enabled hardware, the overall hardware bill of materials can be reduced and as components are being removed, and incidentally reducing risks of hardware failure.
The development of TEEs is driven by standards, such as GlobalPlatform, and this brings predictability and interoperability. This means that device OEMs and third parties, can develop Trusted Applications to support an ever-growing list of platform security requirements.
[Operating mode]
MSG 07:04:47.945 IMS/High [ICSDPLHandlerVOWIFIDisabled.cpp 484] ICSDPLHandlerVOWIFIDisabled::ProcessCallCtrlCB | oprt mode (lpm on/off, etc.) - 61 ICSDPLHandlerVOWIFIDisabled.cpp00484 ICSDPLHandlerVOWIFIDisabled::ProcessCallCtrlCB | oprt mode (lpm on/off, etc.) - 6
Source: https://github.com/jrspruitt/ubi_reader/blob/master/README.md#extracting-images
sudo apt-get install ubi_reader
ubireader_extract_files [options] path/to/file
The script accepts a file with UBI or UBIFS data in it, so should work with a NAND dump. It will search for the first occurance of UBI or UBIFS data and attempt to extract the contents. If file includes special files, you will need to run as root or sudo for it to create these files. With out it, it'll skip them and show a warning that these files were not created.
Source https://blog.csdn.net/qq_41209741/article/details/114634362
文章目錄
Introduction
Definitions
3. 服務和服務要素
3.1 Basic services
3.2 Short Message Service elements
3.2.0 Introduction
3.2.1 有效期
3.2.2 服務中心時間戳
3.3.3 協議標識符
3.3.4 More Message to Send
3.3.5 優先和非優先信息的傳遞
3.3.6 Message Waiting
3.2.7 Alert-SC
3.2.7a MT Correlation ID
3.2.9 Status report capabilities
3.3 Unsuccessful short message TPDU transfer SC > MS
3.3.1 Errors occurring during transfer of TPDU to MS
3.3.2 Errors occurring after TPDU arrives at MS
3.4 Unsuccessful short message TPDU transfer MS->SC
3.4.1 Errors occurring during transfer of TPDU to SC
3.4.2 Errors occurring after TPDU arrives at SC
3.5 將補充業務與短消息業務結合使用
3.6 運營商決定限制在短消息業務中的適用性
3.7 多條短消息傳輸
3.8 短信和互聯網電子郵件互通
3.9 短信壓縮
Introduction
短消息服務（SMS）提供了一種向GSM/UMTS/EPS手機發送有限大小消息的方法。短信服務的提供利用了一個服務中心，作為短信息的儲存和轉發中心。因此，GSM/UMTS/EPS-PLMN需要支持服務中心和移動台之間的短消息傳輸。
移動源消息應從MS傳輸至服務中心。這些用戶可能是為其他移動用戶或固定網絡上的用戶指定的。移動端接信息應從服務中心傳輸到移動終端。這些信息可由其他移動用戶（通過移動源短消息）或各種其他來源（如語音、電傳或傳真）輸入服務中心。
Definitions
alert-SC：由GSM/UMTS PLMN提供的服務單元，用於通知先前向特定MS發起了不成功的短消息遞送嘗試的SC，該MS現在被PLMN識別為已恢復操作
status report：SC通知發起MS提交給SME的短消息的結果
Gateway MSC For Short Message Service(SMS-GMSC)：MSC的功能，能夠從SC接收短消息，詢問HLR路由信息和SMS信息，並將短消息傳送到VMSC或接收方MS的SGSN
IP-Short-Message-Gateway (IP-SM-GW)：負責基於IP的UE和SC之間的協議互通的功能
Loop Prevention (LP)：允許SMS應用程序禁止轉發或自動生成可能導致無限循環的消息的信息元素。
Messages Waiting (MW)：使PLMN存儲信息（消息等待指示）的服務元素，列出那些嘗試向該PLMN中的MS發送短消息失敗的SCs
Messages Waiting Indication (MWI)：要存儲在與MS相關聯的HLR和VLR中的數據，指示在一組SCs中有一個或多個消息等待被傳送到MS（由於不成功的傳送嘗試）
Messages Waiting Data (MWD)：MWI（消息等待指示）的一部分，存儲在HLR中。MWD由SMSC（短消息服務中心）的地址列表組成，該地址列表中有等待發送到移動設備的消息。
Home Location Register(HLR)：歸屬位置寄存器是在蜂窩網絡中找到的數據庫。它除了存儲基於位置區域的信息外，還存儲與服務和功能相關的訂戶數據。
Mobile Management Entity (MME)：為位於指定為MME區域的地理區域中的移動站執行分組交換功能的交換機
Mobile-services Switching Centre (MSC)：為位於指定為MSC區域的地理區域中的移動台執行交換功能的交換機
Mobile Station Memory Capacity Exceeded Flag (MCEF)：部分MWI存儲在HLR中。
MCEF是一個布爾參數，指示MWD的地址列表是否包含一個或多個條目，因為向MS傳遞短消息的嘗試失敗，並導致MS內存容量超出
Mobile Station Not Reachable Flag (MNRF)：部分MWI存儲在VLR、MME和HLR中。MME支持本文件中規定的與MNRF有關的VLR的所有要求。
MNRF是一個布爾參數，指示MWD的地址列表是否包含一個或多個條目，因為向MS發送短消息的嘗試失敗了，原因是訂戶不在。
Mobile station Not-Reachable-for-GPRS (MNRG)：部分MWI存儲在SGSN和HLR中
MNRG是一個布爾參數，指示MWD的地址列表是否包含一個或多個條目，因為向MS傳遞短消息的嘗試失敗，原因是用戶缺席
Mobile Station Not Reachable-via-the-MSC-Reason (MNRR-MSC)：MWI在HLR中的一部分，當在MSC向MS發送短消息的嘗試失敗並導致用戶缺席時，它存儲MS缺席的原因
Mobile Station Not Reachable-via-the-SGSN-Reason (MNRR-SGSN)：MWI在HLR中的一部分，當在MSC向MS發送短消息的嘗試失敗並導致用戶缺席時，它存儲MS缺席的原因
More Messages To Send (MMS)：信息元素，提供一個MS接收來自SC的短消息的時候，信息是否還有更多的消息等待從該SC發送到MS
Service Centre (SC)：負責在SME和MS之間中繼、存儲和轉發短消息的功能
Short Message Entity (SME)：可以發送或接收短消息的實體。
SME可以位於固定網絡、MS或SC中。
SMS STATUS REPORT：短消息傳輸協議數據單元，向接收MS通知由MS先前提交的源於移動的短消息的狀態，即SC是否能夠轉發該消息，或者該消息是否被存儲在SC中以供稍後傳送
SMS COMMAND：短消息傳輸協議數據單元，使MS能夠在SC調用操作
例如，MS可以刪除短消息、取消TP狀態報告請求、查詢短消息的狀態或請求由SC執行的另一功能。
SMS DELIVER：包含用戶數據（短消息）的短消息傳輸協議數據單元，從SC發送到MS
SMS SUBMIT：包含用戶數據（短消息）的短消息傳輸協議數據單元，從MS發送到SC
TPDU： Transfer protocol data unit，傳輸協議數據單元
3. 服務和服務要素
3.1 Basic services
MS狀態改變：從連接態到空閒態，從空閒態到連接態，或者正在Handover的時候，短信傳輸可能會失敗。
還有可能依次接收具有相同的起始地址和標識的兩個短消息，即消息參考號（MO）或SC時間戳（MT）。這種情況可能是由於RP或CP層（例如，在MSC間切換期間）的錯誤造成的，其中它可能是重複的消息，否則它可能是有效的新消息。
因此，接收實體應規定檢查短消息中包含的其他參數，以確定是否要丟棄第二條短消息。在Android中，如果下面6個信息都相同，則判斷為同一條短信，將第二條丟棄：
發端address
MO號碼
count總數
序列號
時間戳
消息內容
(其中count和序列號是針對：用於連接多部分SMS消息的字段)
3.2 Short Message Service elements
3.2.0 Introduction
短信包括8個要素，特別是提交和接收消息：
有效期；
服務中心時間戳；
協議標識符；
More Message to Send；
優先級；
Message-Waiting；
Alert-SC。
MT相關ID。
3.2.1 有效期
TP Validity Period參數值表示短消息有效的時間段，即在向接收者發送之前，SC應保證短消息在SC存儲器中存在多長時間。
3.2.2 服務中心時間戳
服務中心時間戳是一種信息元素，通過它，服務中心將短消息到達服務中心的SM-TL實體的時間通知收件人MS。時間值包含在每個發送給MS的SMS中。
3.3.3 協議標識符
協議標識符是信息元素，SM-TL通過該信息元素表示正在使用的高層協議，或者表示與某種類型的遠程信息處理設備的互通。
協議標識符信息元素使用消息類型中的特定字段：
SMS SUBMIT
SMS SUBMIT-REPORT for RP-ACK
SMS DELIVER DELIVER
SMS-DELIVER-REPORT for RP-ACK
SMS_STATUS_REPORT
SMS COMMAND TP Protocol Identifier (TP PID)
3.3.4 More Message to Send
More Messages to Send是SC通知MS在該SC中有一條或多條消息等待發送給MS的信息元素。More Messages to Send信息元素使用message SMS DELIVER，TP More Messages to Send（TP MMS）中的布爾參數。
3.3.5 優先和非優先信息的傳遞
優先級是由SC或SME提供的信息元素，用於向PLMN指示消息是否為優先級消息。
如果MS被確定為暫時不在，則不應嘗試傳遞非優先級消息。
如果MS未被識別為暫時不存在，則應嘗試傳遞非優先級消息，無論MS是否被識別為沒有可用內存容量。
無論MS是否被識別為暫時不存在或沒有可用內存容量，都應嘗試傳遞優先級消息。
3.3.6 Message Waiting
消息等待是使PLMN能夠提供HLR、SGSN和VLR的服務元素，接收者MS與該HLR、SGSN和VLR相關聯的信息，即在發起SC中有消息等待被遞送到MS。該服務元素僅在先前針對非單個短消息的由於手機暫時不在或MS內存容量超出而導致SM不成功遞送嘗試的情況下使用。
該信息表示消息等待指示（MWI），包括
消息等待數據（MWD）、
GPRS不可到達的移動台（MNRG）、
IP不可到達的UE（UNRI）、
移動台不可到達標誌（MNRF）、
通過MSC不可到達的移動台（MNRR-MSC），
移動不可通過位於HLR中的SGSN原因（MNRR-SGSN）、
UE不可到達原因（UNRR）和移動台存儲容量超出標誌（MCEF）到達；
位於SGSN中的GPRS不可到達移動台（MNRG）和位於VLR中的移動台不可到達標誌（MNRF）。
圖1顯示了一個示例。
圖1 Example of how information on one MS can be put in relation to SC(s)
in order to fulfil the requirement of Alert SC mechanism
MWD應包含一份SCs地址列表（SC Addr），該地址以前曾嘗試過不成功的消息傳遞。為了能夠將警報消息發送給每個嘗試向MS發送非單次SM的SC，HLR應存儲IMSI-Alert以及SC地址的參考。
3.2.7 Alert-SC
Alert-SC是服務元素，它可以由一些GSM/UMTS plmn提供，以通知SC MS：
由於無法訪問MS或超出了MS內存容量，傳送嘗試失敗；以及
PLMN現在認為：
a)已恢復操作（例如已響應尋呼請求）；或
b)有新的可用內存（這意味著移動設備是可訪問的）。
SC的重複傳送嘗試可能有兩種類型：
一種重複的傳送嘗試，因為SC已被告知MS處於活動狀態並且可以接收短消息
SC的自主重複交付嘗試。
這兩個選項的應用由SC和網絡的提供商定義。
3.2.7a MT Correlation ID
MT相關ID是僅當接收MS的HPLMN使用SMS路由器或IP-SM-GW時才使用的服務元素。它用於將前向SM操作與先前的信息檢索操作相關聯。
MT相關ID的使用增強了安全性。通過分析在轉發短消息操作中接收到的相關ID，可以容易地從相關信息檢索操作的起源地檢查它，從而導致檢測到“假”和“欺騙”SMS。
在協議層的IMSI IE中使用MT相關ID來代替IMSI。因此，其結構被定義為與該元素完全相同：
圖2 Structure of the MT Correlation
Sender ID：它由9位十進制數字組成，在其使用壽命內應是唯一的。出於安全目的，其值應為隨機分配的數字，而不是順序分配的數字。
3.2.9 Status report capabilities
SMS還向SC提供通知MS先前發送的源於移動的短消息的狀態的能力。消息的狀態可以是：
成功交付給SME；
SC無法將消息轉發給SME。原因可能是永久性或暫時性的錯誤。永久性錯誤可能是，例如有效期過期、SME地址無效。臨時性錯誤可能是，例如SC SME連接中斷，SME暫時不可用。
3.3 Unsuccessful short message TPDU transfer SC > MS
3.3.1 Errors occurring during transfer of TPDU to MS
這些錯誤通常是由於PLMN或MS中的限製或不支持的服務造成的。錯誤指示從SMS GMSC返回給SC，但MS的進一步診斷信息不可用。
3.3.2 Errors occurring after TPDU arrives at MS
SMS-DELIVER_REPORT包含錯誤信息
Error indication Status (Permanent or Temporary) Meaning
Unknown subscriber P The PLMN rejects the short message TPDU because there is not allocated an IMSI or a directory number for the mobile subscriber in the HLR (see 3GPP TS 29.002 [15]).
Teleservice not provisioned P The PLMN rejects the short message TPDU because the recipient MS has no SMS subscription (see 3GPP TS 29.002 [15]).
Call barred T The PLMN rejects the short message TPDU due to barring of the MS (see 3GPP TS 29.002 [15], description of the Barring supplementary service, 3GPP TS 22.004 [3] and 3GPP TS 23.011[7]), description of Call barred due to Unauthorised Message Originator, 3GPP TS 29.002 [15], and description of Operator Determined Barring, 3GPP TS 22.041 [4] and 3GPP TS 23.015 [8]).
Facility not supported T The VPLMN rejects the short message TPDU due to no provision of the SMS in the VPLMN (see 3GPP TS 29.002 [15]).
Absent subscriber T The PLMN rejects the short message TPDU because ①there was no paging response via the SGSN, MSC or both (see 3GPP TS 24.008 [12] & 3GPP TS 29.002 [15])，②the IMSI GPRS or both records are marked detached (see 3GPP TS 29.002 [15]); ③the MS is subject to roaming restrictions (see “Roaming not allowed”, 3GPP TS 29.002 [15]); ④deregistered in the HLR. The HLR does not have an MSC, SGSN or both numbers stored for the target MS, (see 3GPP TS 29.002 [15]); ⑤Unidentified subscriber (see 3GPP TS 29.002 [15]); ⑥MS purged (see 3GPP TS 29.002 [15]) ; ⑦the MS is not registered in the HSS/HLR for IMS; ⑧there was no SIP response received by the IP-SM-GW; ⑨the MS is temporarily unavailable (eg in power saving mode due to eDRX). (The reasons for absence are assigned integer values in table 1a.The appropriate integer value is sent with the absent subscriber error indication as defined in 3GPP TS 29.002 [15])
MS busy for MT SMS T The PLMN rejects the short message TPDU because of congestion encountered at the visited MSC or the SGSN. Possible reasons include any of the following events in progress: ①short message delivery from another SC; ②IMSI or GPRS detach ③Location Update or Inter SGSN Routing Area Update; ④paging; ⑤emergency call; ⑥call setup.
SMS lower layers capabilities not provisioned T The PLMN rejects the short message TPDU due to MS not being able to support the Short Message Service. The short message transfer attempt is rejected either due to information contained in the class mark, or the MSC not being able to establish connection at SAPI = 3 (see 3GPP TS 24.008 [12] and 3GPP TS 29.002 [15]).
Error in MS T The PLMN rejects the short message TPDU due to an error occurring within the MS at reception of a short message, eg protocol error.
Illegal Subscriber P The PLMN rejects the short message TPDU because the MS failed authentication.
Illegal Equipment P The PLMN rejects the short message TPDU because the IMEI of the MS was black listed in the EIR.
System failure T The PLMN rejects the short message TPDU due to network or protocol failure others than those listed above (see 3GPP TS 29.002 [15]).
Memory Capacity Exceeded T The MS rejects the short message since it has no memory capacity available to store the message.
Status：永久或臨時
兩組錯誤指示之間的關係如表1所示。每個錯誤分為“臨時”或“永久”兩類。該分類給出了MS是否可能在合理的時間內變得可實現的指示，並且因此提供了SC要採取的建議操作，即存儲消息以便稍後傳輸，或者丟棄消息。
3.4 Unsuccessful short message TPDU transfer MS->SC
3.4.1 Errors occurring during transfer of TPDU to SC
這些錯誤通常是由於PLMN中的限製或不支持的服務造成的。MSC或SGSN向MS返回錯誤指示，但SC不能提供進一步的診斷信息
3.4.2 Errors occurring after TPDU arrives at SC
SMS-SUBMIT-REPORT包含錯誤信息
3.5 將補充業務與短消息業務結合使用
只有3GPP TS 22.004[3]和3GPP TS 23.011[7]中定義的補充業務的子集可以與短消息業務結合使用。該子集包括以下補充業務：
所有的5個限制服務。
3.6 運營商決定限制在短消息業務中的適用性
網絡特性運營商確定的限制（參見3GPP TS 22.041[4]）適用於短消息服務。
如果短消息由於操作員確定的限製而失敗，則會將適當的錯誤原因返回給發端人
3.7 多條短消息傳輸
為了避免對在服務中心等待的每個消息對移動設備進行尋呼、認證等的需要，SC可以向SMS-GMSC指示有更多的消息要發送。當給出該指示時，將調用MAP過程，以便將該指示傳遞給VMSC，並且在SC中等待的所有短消息都被傳輸之前，VMSC不會釋放MS。
3.8 短信和互聯網電子郵件互通
MT SMS:
[<from address><space>]<message>
MO SMS:
[<to address><space>]<message>
The to address or from address may take the form:
user@domain1.domain2
or
User Name <user@domain1.domain2>
3.9 短信壓縮
短消息可以根據3GPP TS 23.042[26]中描述的壓縮算法進行壓縮。
壓縮和解壓可在SME之間或SME和SC之間進行。
壓縮僅適用於TPDU的TP用戶數據部分。壓縮報頭必須在緊接可能存在的任何TP用戶數據報頭字段之後的TP用戶數據字段的第一個八位字節處開始。
————————————————
版权声明：本文为CSDN博主「奄奄不息」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_41209741/article/details/114634362
>安卓手機可以安裝LTE
Discovery來觀察. TSU上可以安裝LTE
Discovery來觀察嗎?
尝试下载了一个
LTE Discovery apk
Adb install XXX.apk
然后怎么启动？ 能给一个 adb shell start am -n Packagename/ActivityName
的命令吗？ActivityName不知道。