Edison's NoteSsss

Everything about me

Oculus Rift game prototype show

很久不写blog~ just update一下
这是我最近在做的东西
自从尝试了Oculus Rift 灵感不断
感觉太爽了 真是好东西 回去之后一定要买!

Same video as above just for someone who can’t got youtube!

Compiler Android 4.2 for Nexus 7 in Mac 10.8.2 with Xcode 4.5

上周托朋友在Amazon上买了一台 Nexus7 这周就能到手

再到手之前照例要做功课,其实买来之前就已经研究过很久了,当时犹豫是要Ipad mini还是搞Nexus7, 只有又一次路过Yodubashi实际摸了摸mini之后,感觉还是来个实用的有乐趣设备吧,能拿到完整source code对我这种靠Android吃饭的人来说是很巨大的吸引力啊。。。于是。。搞了!

既然订单下了,那就要开始搞source code和编译了。其实编译环境完全没有压力,我有以前工作用的完整的ubuntu虚拟机编译环境,但是这次我觉得可以搞一下Mac原生的编译环境。。AOSP对Mac的支持还是很友好的,不像某些无良公司。。。完全没有Mac的编译支持!

决定了那开始下代码搞起 先按照Android官网的配置搞定大概的编译环境,很简单不多说,网站列一下

  • http://source.android.com/source/initializing.html

然后开始下载代码(我尝试过使用打了tag的4.1.2分支和4.2分支都失败了。。最后都是用master编过的。。所以我劝大家如果要搞的话安安稳稳的用master吧。。。)

  • repo init -u https://android.googlesource.com/platform/manifest
  • repo sync -j8

 

12-21 ** FIX **
还需要去网站下载二进制驱动包打入source中,下载地址:
https://developers.google.com/android/nexus/drivers#grouperjop40c
否则会出现无法启动的情况。。。

之后就是常规编译步骤了

  • . ./build/envsetup.sh
  • lunch full_grouper-userdebug
  • make all -j8 (如果不想用apple llvm编译的话 可以使用 make CC=”gcc-apple-4.2″ CXX=”g++-apple-4.2″ -j8)

我的编译选项的输出如下:

 lunch full_grouper-userdebug  
============================================  
PLATFORM_VERSION_CODENAME=AOSP 
PLATFORM_VERSION=4.2.42.42.42 
TARGET_PRODUCT=full_grouper 
TARGET_BUILD_VARIANT=userdebug 
TARGET_BUILD_TYPE=release 
TARGET_BUILD_APPS= 
TARGET_ARCH=arm 
TARGET_ARCH_VARIANT=armv7-a-neon 
HOST_ARCH=x86 HOST_OS=darwin 
HOST_OS_EXTRA=Darwin-12.2.0-x86_64-i386-64bit 
HOST_BUILD_TYPE=release BUILD_ID=JB_MR1 OUT_DIR=out 
============================================= 

需要注意的是 如果你使用10.6以上的Mac版本(现在使用10.6以下的也不多了吧。。。) 需要先export一个环境变量

 build/core/combo/HOST_darwin-x86.mk:62: 
**************************************************** 
* build/core/combo/HOST_darwin-x86.mk:63: 
* Cannot find SDK 10.6 at 
*    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk 
*    build/core/combo/HOST_darwin-x86.mk:65: 
* If you wish to build using higher version of SDK, build/core/combo/HOST_darwin-x86.mk:66: 
* try setting BUILD_MAC_SDK_EXPERIMENTAL=1 before build/core/combo/HOST_darwin-x86.mk:67: 
* rerunning this command build/core/combo/HOST_darwin-x86.mk:69: 
***************************************************** 
build/core/combo/HOST_darwin-x86.mk:70: 
*** Stop.. Stop. 

按照提示

  • export BUILD_MAC_SDK_EXPERIMENTAL=1

然后就可以开始正常编译 编译完成后可以在$OUT目录找到生成的img文件 我的out目录的ll如下:

 total 823584 
-rw-r--r-- 1 edison staff 22 Nov 15 10:17 android-info.txt 
-rw-r--r-- 1 edison staff 5113856 Nov 15 11:05 boot.img 
-rw-r--r-- 1 edison staff 25701 Nov 15 11:49 clean_steps.mk 
drwxr-xr-x 2 edison staff 68 Nov 15 10:16 data 
-rw-r--r-- 1 edison staff 113699883 Nov 15 11:52 full_grouper-ota-eng.edison.zip 
-rw-r--r-- 1 edison staff 44690 Nov 15 11:15 installed-files.txt 
-rw-r--r-- 1 edison staff 4871932 Nov 15 10:41 kernel 
drwxr-xr-x 12 edison staff 510 Nov 15 11:15 obj 
-rw-r--r-- 1 edison staff 602 Nov 15 11:49 previous_build_config.mk 
-rw-r--r-- 1 edison staff 766760 Nov 15 11:05 ramdisk-recovery.img 
-rw-r--r-- 1 edison staff 237689 Nov 15 11:05 ramdisk.img 
drwxr-xr-x 3 edison staff 102 Nov 15 11:05 recovery 
-rw-r--r-- 1 edison staff 5642240 Nov 15 11:05 recovery.img 
drwxr-xr-x 8 edison staff 816 Nov 15 11:05 root 
drwxr-xr-x 4 edison staff 170 Nov 15 11:05 symbols 
drwxr-xr-x 13 edison staff 476 Nov 15 11:11 system 
-rw-r--r-- 1 edison staff 184454092 Nov 15 11:15 system.img 
-rw-r--r-- 1 edison staff 106788356 Nov 15 11:05 userdata.img 

其中的full_grouper-ota-eng.edison.zip 是用otapackage编出来的 暂时还没搞明白用途。。。。

  • make otapackage -j8

我使用master分支 基本都是一次编过 没有任何编译错误 但是使用打了tag的分支 没有一次能顺利编过的。。。。

好了 先写这些 等拿到了nexus7 再继续写烧机的经过吧

理解Git工作流

From: http://heikezhi.com/2011/08/04/understanding-the-git-workflow/

如果你不了解Git背后的设计初衷,那么你正处在危险境地,当然有很多参数可以强迫Git按照你的意愿行事,但这并不是Git被设计的工作方式,这就好比你可以把改锥当锤子使用,并且它也可以完成工作,但这对改锥没什么好处。

下面就让我们来看一个最常见的Git工作流是如何变得没法收拾的。

首先从Master创建一个新分支,在这个分支上完成你的工作,然后将它合并回Master分支。

大多数情况下这不会有什么问题,你都会得到你预期的结果,这是因为在你创建新分支之后,Master的代码已经发生了变化。但是有一天,你合并了一个新特性到Master,不过这次Master的代码并没有发生变化,所以同以往不同,这次Git直接将Master指向了你的特性分支上的最后一个Commit,也就是“fast forwards”(见图),而不是创建一个合并commit。

不幸的是,你的新特性分支可能会包含一些checkpoint commits,这些小的commit保证了你的工作不会意外丢失,但是也让你的代码进入了相对不稳定的状态,现在你已经无法从Master的稳定commit中区分这些不稳定的commit了,一旦需要回滚,你很容易就会陷入灾难之中。

当然你可以添加一条规则:“只要是合并新特性时,都必须使用-no-ff来强制生成一个新的commit。”这样问题就解决了,于是你继续往下走。

直到有一天你在Production发现了一个严重的bug,你需要追踪这个bug是何时被引入的,于是你试图通过bisect来找出答案,但却总是找到那些checkpoint commit,于是你放弃了,并开始手动检查。

最终你将Bug定位到了某个单独的文件上,你想通过blame来查看过去48小时这个文件发生的变化,但是你发现这是不可能的,因为blame报告这个文件已经有几个星期没人碰过了,事实证明blame报告的是你最初的commit,而不是合并时的,你的第一个checkpoint commit在几周之前改变了这个文件,但是这个改变直到今天才被合并进来。

-no-ff标识就这样神奇的破坏了bisect和blame,就像你将改锥当做锤子一样。

重新考虑版本控制

版本控制系统的出现是为了解决2个问题

第一个问题就是帮助你更好的编写代码,你需要同你的团队成员同步代码,并且备份你的工作,通过Email发送压缩文件明显不是个靠谱的办法。

第二个问题就是配置管理,这主要是针对并行开发的管理,比如你需要在开发下一个大版本的同时,继续修复当前production版本存在的bug,配置管理也可以用来查找变更,但是这对于诊断Bug用处不是很大。

通常来说,这两个目的是矛盾的。

当你为一个新特性开发原型时,你应该不断的添加checkpoint commit,尽管如此,这些commit通常会破坏测试。

在一个理想的世界中,你的版本历史中的每次变更都应该是简明并且稳定的,不应该有checkpoint commit这种东西来制造噪音,也不应该有巨无霸,比如10,000行代码的commit,干净的提交历史让你可以很容易的撤销变更,或是在分支之间使用cherry-pick,干净的提交历史也让后期的代码检查和分析变得更简单。尽管如此,维护一个干净的提交历史记录却意味着你需要等待一切都变得完美之后再进行提交。

那么我们应该选择哪种策略呢?经常性的提交,还是保证提交历史干净整洁?

如果你是在一个产品还未发布的2人创业公司工作,干净的提交历史对你带来的好处非常有限,你可以把所有的commit都扔到Master,并在任何你需要的时候进行部署。

然后随着变更的增加,以及团队规模或是你的用户基数的增长,你需要工具和技术来确保所有事情都是经过检查的,这通常包括自动化测试,代码检查,以及干净的提交历史。

特性分支看起来是个不错的选择,它们解决了最基本的并行开发问题,但是在你写代码的时候,你迟早会开始考虑最后的集成问题。

当你的项目变得足够大时,简单的分支/提交/合并策略就变得不再奏效了,作坊式的开发时代已经结束了,你需要一个干净的提交历史。

Git的革命性就在于它很好的同时解决了这2个问题,让你在分支上开发新特性时,可以随时提交你的任何变更,并且在随后合并时,你依然可以得到一个干净的提交历史,如果这是你想要的,那么你就应该遵从Git的默认设置。

Git工作流

考虑下这两种类型的分支:公共和私有

公共分支保存着这个项目的权威历史,在公共分支上,每个提交都应该是简明,原子的,并且提交信息应该准确表达变更,同事应该尽可能的保证提交是线性的,并且是永久的,公开的分支包含Master以及Release分支。

而私有分支是属于你自己的,它就相当于你解决问题时候用到的草纸。

将私有分支存在本地是最安全的,如果你需要在你的工作电话和家庭电脑之间同步,最好告诉你的同事你推送的是一个私有分支,以防止他们在这个分支上进行开发。

永远不要把你的私有分支直接合并到任何公共分支上,而应该先使用reset,rebase,squash merges或者commit amending这样的工具清理你的分支。

你可以把自己想象成一个作家,并且将每个commit看做是一本书的章节,作家不会发布第一版手稿,Michael Crichton说过,“好书不是写出来的——而是改出来的”。

如果你使用的是其它系统,你可能会觉得修改历史是不可能的,所有提交就像刻在了石头上一样,是不可改变的,按照这个逻辑,那我们就应该在文本编辑器中禁用撤销功能。

实用主义者一般会直到事情变得不可收拾之时才会注意到问题的存在,对于配置管理来说,我们关心的是全局的变更,checkpoint commit仅仅只是为了方便撤销而保存的缓冲而已。

如果你认为你的公共历史是干净的,那么fast-forward合并不仅很安全,而且很可取,他们保证版本历史是线性的并且非常容易追踪。

而-no-ff参数唯一的作用就是“文档”,有人或许会使用merge commit的消息来表示最后一次合并到production代码中的版本信息,但是这是不对的,你应该使用tag。

根据我修改的代码量,以及修改的时间跨度,还有这个分支偏离Master的程度,我设定了3中基本的工作流。

短期开发

大多数情况都是这样,我通过squash merge来完成清理工作。

假设我创建了一个特性分支,并在接下来的一个小时做了许多checkpoint 提交。

git checkout -b private_feature_branch
touch file1.txt
git add file1.txt
git commit -am “WIP”

在我完成我的工作之后,我会运行下面的命令来完成合并:

git checkout master
git merge –squash private_feature_branch
git commit -v

然后花上一分钟详细的写上这次变更的注释。

大改动

有时一个特性可能需要几天才能够完成,并且包含许多小的提交。

这时我认为我的改动将会被打碎成许多更小的改动,所以squash在这种情况下就拍不上用场了(作为我的一条经验法则,我会问自己”这样有利于代码检查吗?“)

如果我的checkpoint commit包含逻辑上的递增,我可以使用rebase的互动模式。

互动模式非常强大,你可以使用它来编辑老的commit,分割它们,重新排序,在某些情况下,你还可以压缩(squash)它们。

我会在特性分支上执行:

git rebase –interactive master

它会打开一个编辑器,每一行包含一个commit,有SHA1以及commit的message,并且每个commit后面还会跟随一个可以执行的命令列表。

默认情况,每个commit都使用‘pick’,这不会改变commit。

pick ccd6e62 Work on back button
pick 1c83feb Bug fixes
pick f9d0c33 Start work on toolbar

我将这个操作改成了squash,这就会将第二个commit压缩到第一个commit中。

pick ccd6e62 Work on back button
squash 1c83feb Bug fixes
pick f9d0c33 Start work on toolbar

当我保存并关闭之后,会出现一个新的文本编辑器提示我为这些合并后的commit填写一个commit message,然后一切就绪。

废弃旧分支

如果我的特性分支已经存在了太久时间,并且我需要合并几个分支到我的特性分支以保证它是最新的,这样事情就变得错综复杂了,这时你可以很容易的获取原始的diff并创建一个干净的新分支。

git checkout master
git checkout -b cleaned_up_branch
git merge –squash private_feature_branch
git reset

现在我就有了一个新的分支,既有最近的Master上的commit,又有我上一个分支上的工作,现在我可以手动添加并提交我的变更了。

总结

如果你没有遵从Git的默认设置,那么你应该问问自己为什么?

你应该保证公共历史是永久的,原子的,并且易于追踪,而将私有分支看做是临时的,可丢弃的。

因此,理想的工作流应该是:

  1. 从一个公开分支创建一个似有分支。
  2. 经常新的在似有分支上提交你的工作
  3. 一旦你的代码已经完美了,那么清除它的历史
  4. 合并干净的分支到你的公共分支

特别感谢@joshaber以及@jbarnette提供反馈。

————–
本文翻译自”Understanding the Git Workflow”,作者:Benjamin Sandofsky,翻译:@yuanyiz

SMS CALL FLOW BETWEEN GSM AND CDMA NETWORK

SMS CALL FLOW

 

The above fig illustrates sms flow between GSM and CDMA network.CDMA network uses the concept of sudo HLR for SMS routing.
·         MOBILE subscriber from GSM network initiates an Originating SMS to be delivered to a CDMA network.
·         Now MSC A forwards the SMS packet to SMSC-A (MO-FORWARD-SM).
·         ROUTING USES SCCP CALLING ADDRESS: GT OF MSC AND
SCCP CALLED ADDRESS GT OF SMSC(SERVICE CENTRE ADDRESS)
·         INFORMATION CONTANS: SMS,A NUMBER, B NUMBER, SC ADDRESS
·         SMSC AFTER CHECKING BASIC AUTHENTICATION, RESPONDS WITH MO-FORWARD-SM-ACK
·         ONCE THIS ACK REACHES TO HANDSET, ORIGINATOR KNOWS THAT HIS MESSAGES HAS BEEN SUBMITED INTO THE SMSC
·         NOW SMSC NEEDS TO KNOW THE LOCATION OF SUBSCRIBER B. SO SMSC INITIATES SRI QUERY(SEND ROUTING INFORMATION). SMSC    SENDS THE PACKET TO GW MSC-A, WHICH FURTHER FORWARDS TO CDMA-GWMSC.
·         CDMA GWMSC FORWARDS THIS PACKET TO PSEUDO-HLR (RESIDES WITHIN SMSC-B).
·         PSEUDO-HLR RESPONDS WITH A FAKE-IMSI, FAKE-VLR ADDRESS(GT OF SMSC-B)
·         SMSC DOES NORMAL MT-FSM TO THIS FAKE-VLR GT RECEIVED IN SRI-ACK.
·         SMSC-B RESPONDS TO THIS MT-FSM WITH MT-FSM-ACK.
·         SMSC-A KNOWS THAT ITS MESSAGE HAS BEEN DELIVERED AND INFORMS ORIGINATOR SUBSCRIBER IF “STATUS-REPORT” HAS BEEN REQUESTED.
·         SMSC-B NEEDS TO KNOW WHERE ITS CDMA SUBSCRIBER B IS LOCATED
·         SO SENDS SMS-REQ MESSAGE TO LOCAL HLR.ONCE THE LOCATION OF SUBSCRIBER IS KNOW
·         SMS IS DELIVERED USING MT-SMDPP MESAGE.

转自:http://whytelecom.com/content/sms-call-flow-between-gsm-and-cdma-network

3GPP 协议导读

很有用的资料 做个备份~
转载自 kiah_sala
最终编辑 rdstop
24.008 Mobile radio interface Layer 3 specification;
Core network protocols; Stage 3
Must Have
這是我最常用到的spec之一,對我而言也是最入門的一份。大多數spec是用來查的,但是這份從第四章開始是可以一頁頁讀過的。它定義了Mobility Management(MM/GMM)、Call Control(CC)、Session Management(SM)的程序還有OTA Message封包內容(照spec本身的用字:定義radio interface procedures)。另外,要找MM/SM的Timer,要找error cause (CC/GPRS SM)也都是這份。
25.331 Radio Resource Control (RRC);
Protocol specification
Must Have
份量很驚人的一份常用spec。比較難逐頁讀起,因為有很多程序性的東西。通常是用想的,把程序背後的邏輯想懂,不然就是多查幾次就會記起來。那張很有名的RRC States and State Transitions就定義在這份裡面。另外,所有的System Information Block、RRC程序、Handover程序、RAB程序、PAGING TYPE 1和PAGING TYPE 2的格式與定義,還有那堆幾a幾b幾c幾d..的measurements全都在這邊。讀完24.008和25.331算是可以解決掉7成以上的OTA message,剩下的,它們會幫忙refer來refer去。RRC protocol Timer請查這份。
23.060 General Packet Radio Service (GPRS); Service description;Stage 2 Must Have
PS domain的重量級spec。那張有名的GPRS Core Network的架構圖、一堆u-plane、c-plane的堆疊架構圖、UE Operation Mode分成class A, class B, class C(此分類適用於所謂俗的2G… 即A/Gb mode… 詳見22.060)或PS/CS mode(此分類僅適用通俗所謂3G… 即Iu mode)、Packet Data Protocol States、兩個domain的Paging Co-ordination通通都在這邊。PDP Context Preservation在第9章。
27.007 AT command set for User Equipment (UE) Must Have
AT command的兩份spec之一,收錄和SMS沒有直接關係的部份。還是新人的時候,我幾乎是每天抱著這份spec一邊啃一邊試的。離開新人時代,這份的查詢度也還經常居高不下。+CNUM, +CIMI, +CREG, +CGREG, +CLCC, +CGACT, +CLCK, +CLIP, +CGDCONT, +CGATT, +CFCC, +COPS, +CRSM等等等都在這份囉。雖然這份也有一語帶到+ES,但是它是躲在要coco的ITU-T V.250裡。
25.401 UTRAN overall description Must Have
這不算一份常用spec,但是這是一份3GPP新鮮人該翻翻的spec。5.1開宗明義畫清楚core network、UTRAN和UE間的關係,接著畫分User Plane和Control Plane的概念,再來,有一張UTRAN Architecture,讓人看清楚Iu、Iur、Iub三種Interface到底在誰和誰中間,還有RNS、RNC、Node B和cells間的關係。透過這張圖也可以簡單地了解為甚麼會有serving RNS、drift RNS的概念,這樣,s-RNTI、d-RNTI、c-RNTI、u-RNTI這些名詞不用背也可以記得清楚囉。
24.007 Mobile radio interface signalling layer 3;
General aspects
Must Have
這份比較屬於舊GSM範圍,比較少用到,通常是碰到TI solution才會查到它。它會被我列成must have是因為它有一張很經典的Protocol architecture of Non Access Stratum (CS/PS MS side)的架構圖,可以讓我們一眼看清RR, (G)MM, CM(CC/SM/SS/SMS)的關係。
25.301 Radio Interface Protocol Architecture Must Have
頁數算很少,但是算非常架構性的一份大spec,要知道L1、L2、L3倒底差在哪,還有各層間的channel到底怎樣mapping,都在這份。這應該也是比較算用來查的spec,對一個新手而言,光是看到一大堆channel卻不了解它們究竟是做什麼的時候,這份 spec應該很難看得進去。另外,R6起就同時收有分別屬HSDPA/HSUPA的HS-DSCH/E-DCH definition,這份就不重複列在下面的HS spec專區了。
27.005 Equipment (DTE – DCE) interface for Short Message Service (SMS) and Cell Broadcast Service (CBS) Must Have
兩大AT command spec之一,這份從名字可以知道是和SMS還有CBS有關的。較常用的標的有+CMT (MT SMS)、+CMGS (MO SMS)、CMGR (SMS read from USIM/memory)、+CMGW (SMS write to USIM/memory)、+CSCA (Service Centre Address)
23.040 Technical realization of the Short Message Service (SMS) Must Have
顧名思義就是SMS,要看懂CP Data就找它囉,做USIM的OTA download也會用到。另外,做到NITZ的話會refer到定義time/timezone的部份。這份的好朋友是23.038。
23.038 Alphabets and language-specific information Must Have
從頁數看很羽量級的spec,但是包含Data Coding Scheme和GSM 7-bit Packing兩個重要的主題。這份做MWI(Message Waiting Indication)也會用到。
21.905 Vocabulary for 3GPP Specifications Must Have
3GPP專用小辭典? 第一次遇上什麼不懂的名詞,先來找它就對了。
23.003 Numbering, addressing and identification Must Have
從這份的title很清楚的就可以知道這份文件有什麼,舉凡IMSI、TMSI、P-TMSI、MSISDN、LAI、RAI、CI、CGI、IMEI、IMEISV、TLLI(Temporary Logical Link Identity)等等的構造,還有算IMEI CD需要的Luhn check計算法都在這裡。
24.011 Point-to-Point (PP) Short Message Service (SMS)
support on mobile radio interface
Good to Have
對我來講,這份比較常用的時機似乎大多是用來查sms的error cause,CP-Cause還有RP-ERROR都在這裡頭。
25.101 User Equipment (UE) radio transmission and reception (FDD) Good to Have
☆ Table 5.0是UTRA FDD frequency bands,R6有從Band I到Band VI,R7增加了Band VII、Band VIII、Band IX和Band X,R8更增加到Band XIV,但是各版均加註other frequency bands is not precluded。
☆ Channel Spacing是5MHz、Channel Raster是200kHz,還有UARFCN怎算也是定義在這份。
26.071 AMR speech CODEC; General description It depends
AMR簡介。有那張有名的哪種rate是和那種spec相容的表。這份比較像pointer,叫讀者refer這邊那邊的。
26.101 Adaptive Multi-Rate (AMR) speech codec frame structure It depends
有AMR codec frame format (AMR IF1)和AMR Interface Format 2的結構。也有AMR幾kbps是Frame Type多少等對照表。不過目前我遇到的都是format 2,這份可用之處暫時不多。
26.103 Speech codec list for GSM and UMTS It depends
有Codec Bitmap。我是從24.008被refer過來的,要從CC/SEPUP裡面查support codec的時候會用到。
22.042 Network Identity and Timezone (NITZ); Service description, Stage 1 It depends
NITZ本身就是optional feature,所以這份rating相對給比較低。它有定義NITZ information的傳輸和使用。也有考慮到Local Time Zone (LTZ)、summertime等問題。至於TZ要怎算,請見23.040。
25.304 User Equipment (UE) procedures in idle mode and procedures for cell reselection in connected mode It depends
標題很長,簡而言之就是要怎樣選cell。在idle mode的部份,專注於Access Stratum。對實作而言,這份spec還是有很多曖昧地帶或說空間。 (題外話,每次有PM自以為專業地對著no service的手機喊說”沒有camp到網路”,我就會很想請他們來讀讀這份加24.008。首先,和網路發生關係的動詞是attach,再者,no service的手機,不見得是沒有camp到任何一個cell的。)
23.122 Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode It depends
☆和25.304密不可分的一份spec,這份專門講NAS在idle該怎樣選網路,像是UE在power on的時候是自動或手動分別該如何選。(NAS/AS在idle時的Function要怎分在25.304)Steering of roaming在收到USAT REFRESH command後該怎辦的程序也在這份裡。
☆這份spec裡也有一些GSM COMPACT的線索。[See also 22.011] 23.122比較detail, 22.011講比較overall的構面。
☆從R7開始,可以找到EHPLMN(Equivalent HPLMN),同樣地,要在31.102找到EF EHPLMN(6FD9),也要用R7以上的版本。
22.030 Man-Machine Interface (MMI) of the User Equipment (UE) It depends
– 這份如果站在一般手機使用者的角度來講,應該是比較像”密技”的東西。像是IMEI要按*#06#叫出來,要怎樣按call holding,然後要怎樣把被hold住的call叫回來,怎樣按MultiParty、ECT(Explicit Call Transfer),怎樣註冊/啟動Supplementary Service等等…。
– International Access Function (“+” key)和TON(type of number)的關係
HSDPA / HSUPA related 3GPP specs
HSDPA starts from R5 / HSUPA(EUL) starts from R6
25.308 High Speed Downlink Packet Access (HSDPA); Overall description; Stage 2 HSDPA
☆ HSDPA採adaptive modulation (R6有QPSK[M]和16-QAM[O],R7再增64-QAM[O]), hybrid ARQ等技術達高傳輸率、低延遲。HSDPA所定義的新transport channel是HS-DSCH。
☆ HSDPA New MAC entities [Note]
☆ 第9章可以找到換HS-DSCH cell和Active set update之間的差異和關係。
☆ 這份文的R6和R7有非常大的差異,R7定義到FDD only的HS-DSCH reception in CELL_FACH,打破先前HSDPA只在CELL_DCH的觀念。
25.309 FDD enhanced uplink;Overall description;Stage 2 HSUPA
在這份文件裡,可以找到:
1) 常常被演講文件稱作HSUPA網路架構圖的”Protocol Architecture of E-DCH”
2) HSUPA是由Node B來控制排程(Node B controlled scheduling)
3) UE應該要如何handle “Serving Grant(SG)”
25.321 Medium Access Control (MAC) protocol specification HSDPA/HSUPA
【HSUPA】
☆ 定義隨著EUL而產生的MAC-es/MAC-e這兩個entity。
☆ SG-Table (9.2.5.2.1.1)
25.214 Physical layer procedures (FDD) HSDPA/HSUPA
【HSDPA】
☆ (also refer to 25.211)HSDPA channels and procedures: HS-SCCH(High Speed Physical Downlink Shared Control Channel)、HS-PDSCH(High Speed Physical Downlink Shared Channel)、HS-DSCH (High Speed Downlink Shared Channel)、HS-DPCCH (High Speed Dedicated Physical Control Channel)
☆ CQI(Channel Quality Indicator)的定義和mapping table
【HSUPA】
☆ 定義隨EUL所增加的E-AGCH、E-HICH、E-RGCH
USIM related 3GPP/ETSI specs
31.102 Characteristics of the Universal Subscriber Identity Module (USIM) application
最常用的部份是第4章,有USIM每個欄位(EF; Elementary File)的名稱格式和內容物,USIM phonebook的EF構造在4.4.2,像是Name, Number1在EFADN(Abbreviated dialling numbers)裡頭、Number2在EFANR (Additional Number)裡、EFADN寫不完的寫到EFEXT1等等等…注意,這份沒有包括DFGSM下面的EF,要找像是EFPLMNsel, EFBCCH之類的,請洽51.011.
ETSI 102.221 Smart Cards; UICC-Terminal interface; Physical and logical characteristics
1) [31.101/31.102 vs. 102.221比較] 差別是後者較為廣泛,前者針對3G的USIM.
2) 以下這堆command還有SW(status word)都可以從102.221查。除了做USAT會用到,AT command的+CRSM最後也會refer到這邊(+CRSM各command的p1,p2,p3該是什麼)。READ BINARY, UPDATE BINARY, READ RECORD, SELECT, FETCH, TERMINAL PROFILE, ENVELOPE, TERMINAL RESPONSE, GET RESPONSE
51.011(ETSI TS 151 011) Specification of the Subscriber Identity Module – Mobile Equipment (SIM-ME) interface
☆樓上那份找不到的一些SW在這份裡頭。
☆10.3.7 EF SST (SIM service table) 功能類似於USIM的EF UST,EF SST和USIM的EF UST(USIM Service Table)的Identifier都是6F38,但兩者的bit定義和排列順序都不太一樣。
個人用筆記/INDEX區
21.111 USIM and IC card requirements
[5.2] Unblocking of a blocked PIN shall not be possible. (翻成白話是PUK被鎖就無藥可救。)
21.902 Evolution of 3GPP system
R99, R4, R5, R6的內容差在哪。3GPP的”理念”等等等…
22.011 Service accessibility
international roaming, national roaming, roaming in shared networks。 3.2.2.4.1 FPLMN經過Manual Selection成功註冊到網路後,可從EFFPLMN移除。[note]
22.091/23.091 Explicit Call Transfer (ECT)
22.091是stage 1, 定義ECT怎樣打,還有可以什麼時候trasfer 23.091 (stage 3)有解釋SS-error code還有OTA message的procedure. (Note: 但是就是有operator不照遊戲規則玩…)
23.040 Technical realization of the Short Message Service (SMS)
1) MWI有三個level, 第一個protocol id,第二個Data Coding Scheme,第三個是運用TP-UD (TP-UDH).
2) Figure 9.2.3.24 (GSM 7-bit fill bits)筆記
24.002 GSM – UMTS Public Land Mobile Network (PLMN)
Access Reference Configuration
MS(Mobile Station)和UE(User Equipment)的組成圖. GSM的MS相對於3G的UE。
24.080 supplementary services specification; Formats and coding
查CC/Facility的operation_code(See4.2)
25.215 Physical layer – Measurements (FDD)
Transport Channel BLER (Block Error Rate)
25.306 UE Radio Access capabilities
FDD HS-DSCH physical layer categories (俗稱HSDPA UE Category)
25.423 UTRAN Iur interface RNSAP signalling
C-RNTI的定義和可能的值 (see 9.2.1.14)
25.433 UTRAN Iub interface Node B Application Part (NBAP) signalling
9.2.2.13Dc 可以找到Serving Grant Value可以介於0-38,但是38表示zero grant
44.018 Mobile radio interface layer 3 specification; Radio Resource Control (RRC) protocol
DTM (Dual Transfer Mode)
« Older posts

© 2017 Edison's NoteSsss

Theme by Anders NorenUp ↑