2009年3月31日星期二

MM -> REG命令发送与处理

MM -> REG命令发送:

1. handler file
mmsend.c
mminfo.c
gmminfo.c

2. handler
mm_send_mmr_reg_cnf
mm_send_mmr_plmn_search_cnf
mm_send_mmr_sim_available_cnf
mm_send_mmr_sim_not_available_cnf
mm_send_mmr_service_ind
mm_send_mmr_stop_mode_cnf
...

mm_handle_information
gmm_handle_information

3. cmd id file
reg_mm.h

4. cmd id
typedef enum
{
...

MMR_MM_INFORMATION_IND = 0x81,
MMR_PLMN_SEARCH_CNF = 0x82,
MMR_REG_CNF = 0x83,
MMR_SERVICE_IND = 0x84,
MMR_SIM_AVAILABLE_CNF = 0x85,
MMR_SIM_NOT_AVAILABLE_CNF = 0x86,
MMR_STOP_MODE_CNF = 0x87,
MMR_CAMPED_IND = 0x88,
MMR_EMERGENCY_NUM_LIST_IND= 0x89,
MMR_CELL_SERVICE_IND = 0x8A,
#ifdef FEATURE_HSPA_CALL_STATUS_IND
MMR_HSPA_CALL_STATUS_IND = 0x8B,
#endif
MMR_PH_STATUS_CHANGE_CNF = 0x8C
#ifdef FEATURE_OOSC_SERVICE_STATUS_UI_UPDATE
,MMR_CONN_MODE_SERVICE_STATUS_IND
#endif
} reg_to_mm_cmd_type;


MM -> REG命令处理:

1. Handler file
reg_state.c (case MS_MM_REG)

2. Handler
reg_state_main

3. Command id file
reg_mm.h

4. Command id
typedef enum
{
...

MMR_MM_INFORMATION_IND = 0x81,
MMR_PLMN_SEARCH_CNF = 0x82,
MMR_REG_CNF = 0x83,
MMR_SERVICE_IND = 0x84,
MMR_SIM_AVAILABLE_CNF = 0x85,
MMR_SIM_NOT_AVAILABLE_CNF = 0x86,
MMR_STOP_MODE_CNF = 0x87,
MMR_CAMPED_IND = 0x88,
MMR_EMERGENCY_NUM_LIST_IND= 0x89,
MMR_CELL_SERVICE_IND = 0x8A,
#ifdef FEATURE_HSPA_CALL_STATUS_IND
MMR_HSPA_CALL_STATUS_IND = 0x8B,
#endif
MMR_PH_STATUS_CHANGE_CNF = 0x8C
#ifdef FEATURE_OOSC_SERVICE_STATUS_UI_UPDATE
,MMR_CONN_MODE_SERVICE_STATUS_IND
#endif
} reg_to_mm_cmd_type;

REG -> MM命令发送与处理

REG -> MM命令发送:

1. Handler file
reg_send.c

2. Handler
reg_send_mmr_reg_req
reg_send_mmr_plmn_search_req
reg_send_mmr_act_req
reg_send_mmr_sim_available_req
reg_send_mmr_sim_not_available_req
reg_send_mmr_stop_mode_req
reg_send_mmr_eq_plmn_change_ind
reg_send_mmr_plmn_search_abort_req
reg_send_mmr_ph_status_chng_req

3. Command id file
reg_mm.h

4. Command id
typedef enum
{
MMR_ACT_REQ = 0x01,
MMR_PLMN_SEARCH_REQ = 0x02,
MMR_REG_REQ = 0x03,
MMR_SIM_AVAILABLE_REQ = 0x04,
MMR_SIM_NOT_AVAILABLE_REQ = 0x05,
MMR_STOP_MODE_REQ = 0x06,
MMR_EQ_PLMN_CHANGE_IND = 0x07,
MMR_PLMN_SEARCH_ABORT_REQ = 0x08,
MMR_PH_STATUS_CHANGE_REQ = 0x09,
...
} reg_to_mm_cmd_type;


REG -> MM命令处理:

1. Handler file
mmcoord.c

2. Handler
mmcoord_route_mm_message (case MS_MM_REG)

3. Command id file
reg_mm.h

4. Command id
typedef enum
{
MMR_ACT_REQ = 0x01,
MMR_PLMN_SEARCH_REQ = 0x02,
MMR_REG_REQ = 0x03,
MMR_SIM_AVAILABLE_REQ = 0x04,
MMR_SIM_NOT_AVAILABLE_REQ = 0x05,
MMR_STOP_MODE_REQ = 0x06,
MMR_EQ_PLMN_CHANGE_IND = 0x07,
MMR_PLMN_SEARCH_ABORT_REQ = 0x08,
MMR_PH_STATUS_CHANGE_REQ = 0x09,
...
} reg_to_mm_cmd_type;

MM -> RRC的命令发送与处理

MM -> RRC的命令处理

命令发送

1. Handler file
mmrrcconn.c

2. Handler
send_cmd_to_rrc

3. Comand id file
rrccmd.h

4. Command id
/*--------------------------------------------------------*/
/* Command Ids of RRC commands Sent by MM */
/*--------------------------------------------------------*/

RRC_MM_CMD_BASE = 0x05000000, /* MM commands start here */

/* 0x05000001*/
RRC_SERVICE_REQ,

/* 0x05000002 */
RRC_EST_REQ,

/* 0x05000003 */
RRC_DATA_REQ,

/* 0x05000004 */
RRC_OPEN_SESSION_REQ,

/* 0x05000005 */
RRC_CLOSE_SESSION_REQ,

/* 0x05000006 */
RRC_ABORT_REQ,

/* 0x05000007 */
RRC_PLMN_LIST_REQ,

/* 0x05000008 */
RRC_ACT_REQ,

/* 0x05000009 */
RRC_DEACT_REQ,

/* 0x0500000A */
RRC_STOP_WCDMA_MODE_REQ,

/* 0x0500000B */
RRC_FORBIDDEN_LAI_LIST_UPDATE_REQ,

/* 0x0500000C */
RRC_INVALIDATE_SIM_DATA_REQ,

/* 0x0500000D */
RRC_SIM_INSERTED_REQ,

/* 0x0500000E */
RRC_SIM_UPDATE_REQ,

/* 0x0500000F */
RRC_ACTIVATION_RSP,

/* 0x05000010 */
RRC_CHANGE_MODE_IND,

/* 0x05000011 */
RRC_MODE_CHANGE_REQ,

/* 0x05000012 */
RRC_EQ_PLMN_LIST_CHANGE_IND,

/* 0x05000013 */
RRC_NW_SEL_MODE_RESET_IND,

/* 0x05000014 */
RRC_BPLMN_SEARCH_ABORT_REQ, /* Added for WTOW/WTOG BPLMN SEARCH ABORT */

命令处理
1. Handler file
rrcdispatcher.c

2. Handler
rrc_dispatch_mm_commands

3. Command id file
rrccmd.h

4. Command id
The same with command send

设备无法切换到下载模式

COULDN'T CHANGE PHONE TO DOWNLOAD MODE
This error can have multiple causes.

One cause is the phone has one or more problems switching from DIAG mode to DLOAD (Downloader) mode after successfully receiving the command to do so. Specifically, this is CMD_CODE 58 (Switch to Downloader). QPST has to switch the phone offline (CMD_CODE 68) and then into downloader mode using CMD_CODE 58. The target may not be processing one of those mode change commands properly. To verify, go to the QPST Bin directory, which is typically in "C:\Program Files\QPST\Bin" and search for a file named "Dload_COMx.dbg", where x = the COM port number QPST was using for the previous download attempt. Once you find that file, attach it to your Case for analysis.

If you have QXDM, you can manually command the phone to switch to DLOAD mode by sending the following command:

SendRawRequest "0x3A"

The target should switch to DLOAD mode and indicate that on the UI as well as on the COM port QPST is monitoring. In this state, you can disable the "Auto Backup/Restore" option on QPST and proceed to flash upgrade the target without backing up NV. However, before you do this, it is necessary that you have already created or received a QCN backup file for your particular target. QCN backup files contain target-specific calibration data and can be created manually by using QPST Software Download's BACKUP tab. If you need the QCN for your target, create a Case and include the serial number. Qualcomm can provide the latest QCN backup file from when the device was last calibrated at our factory. Once an upgrade from DLOAD mode completes, the QCN will need to be restored to the device manaully using QPST Software Download's RESTORE tab.

Another possible cause is that once the phone is told to switch to DLOAD mode by QPST, the USB virtual COM port changes to a new port. In this situation, it is helpful to observe the Windows Device Manager on the Ports branch to see if the target re-enumerates on a different port. If it does, QPST will allow you some time to manually browse and reselect the correct COM port before it displays this message. A future version of QPST will automatically follow the ports and select the correct one in these conditions. However, for now, you must always manually connect QPST to the COM port.


The Hardware Watchdog is disabled
QPST needs the Hardware WatchDog enabled for reset and entering into download mode.


COM error 80004005 during SetPhoneMode
When you get this error (captured in the debug file of the COM port to which you're trying to download the software, see example below) generally it is because of one of these reasons:

  • The phone won't switch to offline mode because some phone task is voting against the change.
  • The phone switches offline, but won't switch to download mode.
  • The request to switch to offline or download mode causes the phone to crash or reset.
  • The user is trying to download to a WinMobile phone over TCP/IP. They would have to reconfigure the phone's USB to use composite mode (use the switchUSB application on the phone).
  • The change to download mode was successful but the phone re-enumerated on a different COM port.

Example of debug file with this error:

QPST Software Download 2.7.0.312 DEADD00D SURF1000-800 M6290A-KPRZL-1.2.0070
Modem file (and path for flash programmer): D:\Um\build\ms\bin\KPRZL\amss.mbn
Flash Programmer file: D:\Um\build\ms\bin\KPRZL\NPRG6280.HEX
Sending Diag Ping Command
Jumping to Download Mode
COM error 80004005 during SetPhoneMode
Download end, status 103, error 115
Exit multi-image download with status 0x00000000

关于WCDMA小区重选

RSCP
We can get RSCP from Rx_AGC and Ec/Io.

RSCP=Rx_AGC+Ec/Io


WHICH VERSION OF AMSS SUPPORTS THIS PACKET?
This packet has been supported since AMSS6200 version 4.3 and higher. This packet is generated whenever cells are ranked.


REPORTING INTERVAL
This log packet 0x4005 is reported by L1 when measurements are made for cell reselection only in idle mode/Cell_FACH. This packet is generated whenever cells are ranked.

So this is really event driven, rather than timed and should follow the rules as specified in 25.304 and 25.133.

NW parameters such as the number of neighbors, various kind of neighbors, thresholds associated with serving cell or neighbor cell as well as length of DRX cycle... All that might have an influence on the freq of this log reports.


HOW TO SEE WHEN RESELECTION STARTS AND ENDS
There are 4 Event Reports that can tell you this. Create a Filtered View with Event ID 530-533 enabled.


WCDMA CELL STRUCTURE IS 10 BYTES INSTEAD OF 9
QCT has confirmed that there is bug in the ICD and it will be fixed in next release. QCT is tracking this issue through internal CR 42642.


ONLY MONITORED SET CELLS REPORTED

  • Active cells in list search (0x414F) and active set (0x4110)
  • Intra freq monitored cells in list search and cell reselection (0x4005) and neighbor set (0x4111)
  • Inter rat monitored cells in cell reselection
  • inter freq monitored cells in cell reselection when it will be available.

We don't have a packet that has everything about reselection. The very nature of Cell Reselection makes it difficult to summarize all the info in one place... (Different scenario, different RATs...). With these existing Log packets, we can achieve the primary purpose Understand reelection scenarios and debug potential issues.

IS THIS PACKET ONLY VALID IN IDLE STATE?
Yes, only in idle mode/Cell_FACH. There is an outstanding issue with the log packet - it does not work for inter-frequency in Idle mode (there is a CR already).


CAN WE INCLUDE ADDITIONAL PARAMETERS IN THIS LOG RELATED TO RESELECTION?
The cell reselection information (Qhyst, Treselection) can be found from SIB3 logging in WCDMA Signaling Messages Packet (LOG_CODE 0x412F). You will need to search for the Type3 SIB in the signaling log packets. Treselection is also logged in the diagnostic debug messages when the timer is incremented for neighbor cells. Search for the string "Tresel" in the Mobile Messages window in CAIT, or in LOG_CODE 0x1018.


RSCP UNITS
In packet description for 0x4005 units for RSCP mentioned is dB which is incorrect. It should be in dBm units.

RANK_ECIO

LENGTH
RANK_ECIO is defined in the code as...

int 16 (see below)
/* ECIO rank, range 0..-200, 0xFFFF -> not used */
int16 rank_ecio;

...and how you can see the range is [0.. -200], so an "int16" is actually needed. There is an error in the ICD RANK_ECIO's length.

EC/IO Ranking measurements
Assuming HCS is not used and performing intra-frequency measurements, if there is no penalty time in SIB 11 and Qoffmbms is not requested:
Rs = Qmeas,s + Qhysts
Rn = Qmeas,n - Qoffsets,n
This condition must be verified for t-Reselection-S seconds.

By reporting an example with a generic reference to UE log , considering neighboring cells ranking please refer below:

Qoffsets,n= 4dB

Cell 2:
RF freq = 10563
PSC = 30
ECIO = -2.0
rank_ecio = -12
RSCP = -77
rank_rscp = -81

Rn = -2 -4 = -6
-6*2 = -12 ran
king value

Why values are multiplied by 2: Ec/No values had a 0.5 granularity. When multiplying, it is reconducted to an integer values and comparison ranking move to those values, as also used in most 3GPP specs. Another example:

ECIO = -9.5
rank_ecio = -15

Rs = -9.5 + 2 = -7.5
-7.5*2 = -15

2009年3月26日星期四

注册网络失败后搜索受限服务

1. 问题描述:
当UE进行位置更新被网络拒绝,错误码为以下情况时,UE不再搜索受限服务:
#2 (IMSI unknown in HLR)
#3 (Illegal MS)
#6 (Illegal ME)
#8 (GPRS services and non-GPRS services not allowed)
当进行LU或GMM Attach或RAU被拒绝并且错误码为以上情况,SIM卡状态被标记为无效,而System Determination (SD)会继续发送full service请求。由于SIM卡被标记为无效,所以NAS层会丢弃full service请求。同时由于SD没有请求搜索受限服务,所以UE不会驻扎到可提供受限服务的网络上。

问题重现条件:
1)SIM卡在优先服务域被标记为无效(见下表);
2)UE离开服务区;

+---------------------------+-------------------------------------------------------+
| Preferred Service Domain | SIM state |
+---------------------------+-------------------------------------------------------+
| CS_ONLY | CS_INVALID, CS_PS_INVALID, UNAVAILABLE |
+---------------------------+-------------------------------------------------------+
| PS_ONLY | PS_INVALID, CS_PS_INVALID, UNAVAILABLE |
+---------------------------+-------------------------------------------------------+
| CS_PS | CS_PS_INVALID, UNAVAILABLE |
+---------------------------+-------------------------------------------------------+

以下为测试步骤,UE在第5步时不会驻扎到受限服务网络:
1)UE开机;
2)网络拒绝LU/GMM Attach/RAU,标记SIM卡的优先服务域为无效;
3)在被拒绝的网络中,UE始终处于受限服务状态;
4)如果用户离开网络覆盖区,则UE离开服务区;
5)用户重新回到网络覆盖区,但此时UE并不会重新驻扎到该网络并处于受限服务状态;

注意点:
就算UE没有驻扎到任何网络,当用户发起紧急呼叫时,UE还是会搜索并获取任何可用的小区用于此紧急呼叫。

2. 影响

3. 解决
当SIM卡状态和优先服务域不兼容时,SD会搜索受限服务。

4. 测试步骤
1)UE开机(优先服务域设为CS_ONLY);
2)获得full service;
3)网络发送LU拒绝使得SIM卡状态为CS_INVALID;
4)服务丢失;
5)获得受限服务;
检查第5步是否获得受限服务。

5. 修改文件
services/sd/sd.c
services/sd/sdss.c
services/sd/sdss.h
services/sd/sdssscr.c
services/sd/sdssscr.h

6. 已解决此问题的平台
AMSS 6245
AMSS 6255A
AMSS 6260
AMSS 6280
AMSS 7200
AMSS 6500
AMSS 6550

参考文档:
80-VF746-1_B_Limited_Svc_Scan_after_Reg_Rejection.pdf