shape layout

old/UI Design 2010. 8. 4. 22:06

[shape_counter.xml]

<?xml version="1.0" encoding="utf-8"?>

<!-- produced by lee.hyuntae@btbsolution.co.kr
  for text counter background     -->

<shape
 xmlns:android="http://schemas.android.com/apk/res/android"
    android:shape="rectangle">

    <solid
     android:color="#88000000" />
    <padding
     android:left="7dp" 
        android:right="7dp" />
    <corners
       android:radius="4dp" />

</shape>

'old > UI Design' 카테고리의 다른 글

Shape  (0) 2010.08.10
cutom title bar  (0) 2010.08.04
adb shell에서 특정 activity실행하기  (0) 2010.07.06
PowerManager에서 Screen ON/OFF 통지  (0) 2010.07.06
Resources - Menus, Searchable  (0) 2010.07.01
Posted by jazzlife
,
; 핸들러로 지연시키지 않으면 안 뜬다...이상해...

Handler keyPadHandler = new Handler();
            keyPadHandler.postDelayed(new Runnable() {
                public void run() {
                    if(mRecipientsEditor!= null){
                    if(mRecipientsEditor.getVisibility()== View.VISIBLE){
                        InputMethodManager inputMethodManager =
                            (InputMethodManager)getSystemService(Context.INPUT_METHOD_SERVICE);       
                     inputMethodManager.showSoftInput(mRecipientsEditor, 0);
                    }
                    }
                }
            }, 100);

'old > sms&mms' 카테고리의 다른 글

SMS solicite_eclair  (0) 2010.07.22
Internals of Telephony subsystem  (0) 2010.07.09
The Radio Interface Layer (RIL)  (0) 2010.07.09
Android's Radio Interface Layer(RIL)  (0) 2010.07.08
Complete End to End Call Flow of Short Message Service(SMS)  (0) 2010.07.08
Posted by jazzlife
,

SMS solicite_eclair

old/sms&mms 2010. 7. 22. 12:12
[ComposeMessageActivity.java]
confirmSendMessageIfNeeded()
sendMessage()

[WorkingMessage.java]
send()
sendSmsWorker(conv, msgText)

[SmsMessageSender.java]
sendMessage(threadId)

- frameworks
[SmsManager.java]
1.sendMultipartTextMessage(mDests[i], mServiceCenter, messages, sentIntents, deliveryIntents)
2.sendTextMessage()

[IccSmsInterfaceManager.java] - ISms.aidl (ISms_Stub.java)
권한승인 -  
PhoneBase.getContext().enforceCallingPermission("android.permission.SEND_SMS","Sending SMS message");
1.sendMultipartText(destinationAddress, scAddress, parts, sentIntents, deliveryIntents)
2.sendText(destinationAddress, scAddress, text, sentIntent, deliveryIntent)

[GsmSMSDispatcher.java] - extended SMSDispatcher
1.sendMultipartText(destAddr, scAddr, (ArrayList<String>) parts,(ArrayList<PendingIntent>) sentIntents,
(ArrayList<PendingIntent>) deliveryIntents)
   SmsMessage.getSubmitPdu(scAddress, destinationAddress,parts.get(i), deliveryIntent != null, SmsHeader.toByteArray(smsHeader),encoding)
   sendRawPdu(pdu.encodedScAddress, pdu.encodedMessage, sentIntent, deliveryIntent)

2.sendText(destAddr, scAddr, text, sentIntent, deliveryIntent)
   SmsMessage.SubmitPdu pdu = SmsMessage.getSubmitPdu(scAddr, destAddr, text, (deliveryIntent != null))
   SMSDispatcher.sendRawPdu(pdus.encodedScAddress, pdus.encodedMessage, sentIntent, deliveryIntent)


Posted by jazzlife
,

Internals of Telephony Subsystem

1.1. Part I, the key items

Assumption: We are in the top level of Android source code repository

  • Files
    frameworks\base\telephony  the core of the telephony subsystem implementation, GSM phone and so on
    packages\apps\Phone        Phone application implementation, UI related stuffs reside
    hardware\ril               Radio reference implementation

  • The big picture

  • The key interfaces and classes

    1. Phone interfaces
      Phone.java:Base abstraction of the phone

      frameworks\base\telephony\java\com\android\internal\telephony\Phone.java

      PhoneBase.java:An abstract class which extends Phone interface and implements the Event registration and notification

      frameworks\base\telephony\java\com\android\internal\telephony\PhoneBase.java

      GSMPhone.java:A concrete phone implementation

      frameworks\base\telephony\java\com\android\internal\telephony\gsm\GSMPhone.java

      CommandsInterface.java:Radio operation abstraction

      frameworks\base\telephony\java\com\android\internal\telephony\gsm\CommandsInterface.java

      BaseCommands.java:Radio event registration and notification

      frameworks\base\telephony\java\com\android\internal\telephony\gsm\BaseCommands.java

      RIL.java: Radio interface library implementation, responsible for sending request to Radio layer and
      distribute the response from Radio layer to request sender
       

      frameworks\base\telephony\java\com\android\internal\telephony\RIL.java

      Native stub for RIL.java: communicates with RIL.java through local socket

      hardware\ril\libril\*

      Reference implementation of Radio library:communicates with Radio hardware through AT command

      hardware\ril\reference-ril\*

      Radio interface lib daemon runs as a stand alone process

      hardware\ril\rild\*

    2. RIL request and response
      1, Solicited and Unsolicited response
      Solicited response response to the upper layer request, this is a kind of passive response,
      for instance, response the request of Singal strength request
      Unsolicited response a response triggered by the underlying hardware, for instance, the state change
      Radio will trigger an RIL_UNSOL_RESPONSE_RADIO_STATE_CHANGED response to notify the upper layer

    3. Request sending and handling
      RIL_Sender thread
      gets the reqeust from mRequestsList and send it to Radio reference library through local socket
      RIL Receiver thread
      receives the response from Radio reference library and process it with processUnsolicited()/processSolicited()
      according to response type RESPONSE_UNSOLICITED/RESPONSE_SOLICITED
      processUnsolicited() is responsible for processing active event from Radio layer
      processSolicited() is responsible for processing passive response to upper layer request

    4. Message identity localization and Parcel
      The mechanism used here is localize the identity of message and put it into a Parcel, send it to the target,
      the target receives the Parcel, put the wanted stuffs into Parcel and return back it to the sender, it is
      the sender's responsibility to classify and handle the response corresponds to the specific request.

      We explain this trick by an example, User dialed a number
      *A user's dialing activity runs a long trip to get to the point dial() in RIL.java
      * RILRequest rr = RILRequest.obtain(RIL_REQUEST_DIAL, result);
           send(rr);
           put the RIL_REQUEST_DIAL ID into Parcel embedded in rr and send it to the target, the target here is      reference-ril.c
      * refernece-ril.c receives the request and handle it with requestDial()
      * requestDial() completes it work and send response back by RIL_onRequestComplete()
      * The implementation of RIL_onRequestComplete() resides in ril.cpp
           p.writeInt32 (RESPONSE_SOLICITED);
           p.writeInt32 (pRI->token);
           put the response type to RESPONSE_SOLICITED, because the request is initiated by upper level, and it      is a passive response, put the RIL_REQUEST_DIAL into the Parcel (pRI->token == RIL_REQUEST_DIAL) for      upper layer to handle the response to the RIL_REQUEST_DIAL request.
      * thanks to the local socket, the control flow arrived at RIL.java again, this time it hits at
           RIL_Receiver(),for the reason of RIL_Receiver's listing on SOCKET_NAME_RIL socket
           the RIL_Receiver delegates the response to the processSolicited(), it was responsibility of
           processSolicited() to notify the registrarant according the content of the response.

'old > sms&mms' 카테고리의 다른 글

soft keyboard 출력 방법  (0) 2010.07.22
SMS solicite_eclair  (0) 2010.07.22
The Radio Interface Layer (RIL)  (0) 2010.07.09
Android's Radio Interface Layer(RIL)  (0) 2010.07.08
Complete End to End Call Flow of Short Message Service(SMS)  (0) 2010.07.08
Posted by jazzlife
,

The Radio Interface Layer (RIL)

Introduction

Android's Radio Interface Layer (RIL) provides an abstraction layer between Android telephony services (android.telephony) and radio hardware. The RIL is radio agnostic, and includes support for Global System for Mobile communication (GSM)-based radios.

The diagram below illustrates the RIL in the context of Android's Telephony system architecture.

Solid elements represent Android blocks and dashed elements represent partner-specific proprietary blocks.

The RIL consists of two primary components:

  • RIL Daemon: The RIL daemon initializes the Vendor RIL, processes all communication from Android telephony services, and dispatches calls to the Vendor RIL as solicited commands.
  • Vendor RIL: The radio-specific Vendor RIL of ril.h that processes all communication with radio hardware and dispatches calls to the RIL Daemon (rild) through unsolicited commands.

The RIL Shim Layer

Radio Interface Layer (RIL)

  • HAL interface between the Android TelephonyManager and the baseband modem
  • Voice, Data, SMS, SIM, SIMToolkit
  • Android includes a reference AT command based RIL

RIL API

  • Currently 75 requests (e.g. Dial) and 17 unsolicited responses (e.g. signal strength)
  • Android RIL inspired by GSM TS 27.007
  • Can implement as AT command based or proprietary protocol (e.g. RPCs via shared memory)

Enhancing the RIL

  • Carriers may require specific features (e.g. JCDMA, O2 Homezone)
  • Qualcomm working on adding CDMA and Multi-mode support

Certification

  • GCF
  • CDG

Tips

  • SIM and SIM Toolkit is complex, get an expert
  • RIL needs to provide neighboring cell id (non-standard). Used by Google Maps.
  • Data: suggest packet interface, no DHCP, no PPP.
  • Depending on modem interface, RIL may get complicated with lots of logic/state.
  • Android data is always-on, modem should support dormancy

Architecture overview

Linux手机打电话代码分析(Android) - clarkluo2004 - 天翼的博客

 
RIL
Initialization

Android initializes the telephony stack and the Vendor RIL at startup as described in the sequence below:

  1. RIL daemon reads rild.lib path and rild.libargs system properties to determine the Vendor RIL library to use and any initialization arguments to provide to the Vendor RIL
  2. RIL daemon loads the Vendor RIL library and calls RIL_Init to initialize the RIL and obtain a reference to RIL functions
  3. RIL daemon calls RIL_register on the Android telephony stack, providing a reference to the Vendor RIL functions

See the RIL Daemon source code at /device/commands/rild/rild.c for details.

RIL Interaction

There are two forms of communication that the RIL handles:

  • Solicited commands: Solicited commands originated by RIL lib, such as DIAL and HANGUP.
  • Unsolicited responses: Unsolicited responses that originate from the baseband, such as CALL_STATE_CHANGED and NEW_SMS.

Solicited

The following snippet illustrates the interface for solicited commands:

void OnRequest (int request_id, void *data, size_t datalen, RIL_Token t);
void OnRequestComplete (RIL_Token t, RIL_Error e, void *response, size_t responselen);

There are over sixty solicited commands grouped by the following families:

  • SIM PIN, IO, and IMSI/IMEI (11)
  • Call status and handling (dial, answer, mute…) (16)
  • Network status query (4)
  • Network setting (barring, forwarding, selection…) (12)
  • SMS (3)
  • PDP connection (4)
  • Power and reset (2)
  • Supplementary Services (5)
  • Vendor defined and support (4)

The following diagram illustrates a solicited call in Android:

Unsolicited

The following snippet illustrates the interface for unsolicited commands:

void OnUnsolicitedResponse (int unsolResponse, void *data, size_t datalen);

There are over ten unsolicited commands grouped by the following families:

  • Network status changed (4)
  • New SMS notify (3)
  • New USSD notify (2)
  • Signal strength or time changed (2)

The following diagram illustrates an unsolicited call in Android:

Implementing the RIL

To implement a radio-specific RIL, create a shared library that implements a set of functions required by Android to process radio requests. The required functions are defined in the RIL header (/include/telephony/ril.h).

The Android radio interface is radio-agnostic and the Vendor RIL can use any protocol to communicate with the radio. Android provides a reference Vendor RIL, using the Hayes AT command set, that you can use as a quick start for telephony testing and a guide for commercial vendor RILs. The source code for the reference RIL is found at /commands/reference-ril/.

Compile your Vendor RIL as a shared library using the convention libril-<companyname>-<RIL version>.so, for example, libril-acme-124.so, where:

  • libril: all vendor RIL implementations start with 'libril'
  • <companyname>: a company-specific abbreviation
  • <RIL version>: RIL version number
  • so: file extension

RIL_Init

Your Vendor RIL must define a RIL_Init function that provides a handle to the functions which will process all radio requests. RIL_Init will be called by the Android RIL Daemon at boot time to initialize the RIL.

RIL_RadioFunctions *RIL_Init (RIL_Env* env, int argc, char **argv);

RIL_Init should return a RIL_RadioFunctions structure containing the handles to the radio functions:

type structure {
	int RIL_version;
	RIL_RequestFunc onRequest;
	RIL_RadioStateRequest onStateRequest;      
	RIL_Supports supports;
	RIL_Cancel onCancel;
	RIL_GetVersion getVersion;
} 
RIL_RadioFunctions;

RIL Functions

ril.h defines RIL states and variables, such as RIL_UNSOL_STK_CALL_SETUP, RIL_SIM_READY, RIL_SIM_NOT_READY, as well as the functions described in the tables below. Skim the header file (/device/include/telephony/ril.h) for details.

RIL Solicited Command Requests

The vendor RIL must provide the functions described in the table below to handle solicited commands. The RIL solicited command request types are defined in ril.h with the RIL_REQUEST_ prefix. Check the header file for details.

void (*RIL_RequestFunc)(int request, void *data, size_t datalen, RIL_Token t);

This is the RIL entry point for solicited commands and must be able to handle the various RIL solicited request types defined in ril.h with the RIL_REQUEST_ prefix.

  • request is one of RIL_REQUEST_*
  • data is pointer to data defined for that RIL_REQUEST_*
  • t should be used in subsequent call to RIL_onResponse
  • datalen is owned by caller, and should not be modified or freed by callee

Must be completed with a call to RIL_onRequestComplete(). RIL_onRequestComplete() may be called from any thread before or after this function returns. This will always be called from the same thread, so returning here implies that the radio is ready to process another command (whether or not the previous command has completed).|

RIL_RadioState (*RIL_RadioStateRequest)();

This function should return the current radio state synchronously.

int (*RIL_Supports)(int requestCode);

This function returns “1” if the specified RIL_REQUEST code is supported and 0 if it is not.

void (*RIL_Cancel)(RIL_Token t);

This function is used to indicate that a pending request should be canceled. This function is called from a separate thread–not the thread that calls RIL_RequestFunc.

On cancel, the callee should do its best to abandon the request and call RIL_onRequestComplete with RIL_Errno CANCELLED at some later point.

Subsequent calls to RIL_onRequestComplete for this request with other results will be tolerated but ignored (that is, it is valid to ignore the cancellation request).

RIL_Cancel calls should return immediately and not wait for cancellation.

const char* (*RIL_GetVersion)(void);

Return a version string for your Vendor RIL

The vendor RIL uses the following callback methods to communicate back to the Android RIL daemon.

void RIL_onRequestComplete(RIL_Token t, RIL_Errno e, void *response, size_t responselen);

* t is parameter passed in on previous call to RIL_Notification routine.

  • If e != SUCCESS, then response can be null and is ignored
  • response is owned by caller, and should not be modified or freed by callee
  • RIL_onRequestComplete will return as soon as possible

void RIL_requestTimedCallback (RIL_TimedCallback callback, void *param, const struct timeval *relativeTime);

Call user-specified callback function on the same thread that RIL_RequestFunc is called. If relativeTime is specified, then it specifies a relative time value at which the callback is invoked. If relativeTime is NULL or points to a 0-filled structure, the callback will be invoked as soon as possible.

RIL Unsolicited Commands

The functions listed in the table below are call-back functions used by the Vendor RIL to invoke unsolicited commands on the Android platform. See ril.h for details.

void RIL_onUnsolicitedResponse(int unsolResponse, const void *data, size_t datalen);

* unsolResponse is one of RIL_UNSOL_RESPONSE_*

  • data is pointer to data defined for that RIL_UNSOL_RESPONSE_*
  • data is owned by caller, and should not be modified or freed by callee

The ril source code in userspace

Usefull links

'old > sms&mms' 카테고리의 다른 글

SMS solicite_eclair  (0) 2010.07.22
Internals of Telephony subsystem  (0) 2010.07.09
Android's Radio Interface Layer(RIL)  (0) 2010.07.08
Complete End to End Call Flow of Short Message Service(SMS)  (0) 2010.07.08
Android SMS call analysis  (0) 2010.07.06
Posted by jazzlife
,
RIL 이란 무엇인가?
 
개요.
 
안드로이드 RIL은 android.telephony 서비스들과 radio h/w간의 추상화된 계층을 제공한다.
RIL은 radio agnostic(존재하지만 정확하게 표현하기는 어려운 실체)이며, GSM 기반의 radio들에 대한 지원을 포함하고
있다.
 
아래의 그림은 안드로이드 전화통화 시스템 구조를 설명한다.
 
   
 
위의 그림에서 Radio Daemon과 Vender RIL은 파트너의 특수성을 가진 사적소유영역에 속하며, 나머지 블록은
안드로이드 영역에 속한다고 할 수 있다.
 
RIL은 두가지의 기본적인 컴포넌트로 구성된다.
 
RIL 데몬(Daemon) : 
 
RIL 데몬은 Vender RIL을 초기화하며, 안드로이드 telephony 서비스들로부터의 모든 통신을 프로세스하며,
solicited 명령어를 통해 Vender RIL로 콜을 넘긴다.
 
Vender RIL :
 
ril.h의 radio 특수성을 포함하는 Vender RIL은 radio h/w와의 모든 통신을 처리하며, unsolicited 명령어들을 통해서
RIL 데몬(rild)에 콜을 넘긴다.



 
RIL 초기화
 
안드로이드는 구동시점에 아래에 언급된 순서대로, telephony 스택과 Vender RIL 을 초기화한다.
 
1. RIL 데몬은 Vender RIL에 제공해야할 초기화 argument와 그것을 사용하기 위한 Vender RIL 라이브러리를
   결정하기 위한 rild.lib 경로와 rild.libargs 시스템 속성들을 읽어들인다.
 
2. RIL 데몬은 Vender RIL 라이브러리를 load(탑재)하며, RIL을 초기화하기 위해 RIL_Init을 호출하며,
    RIL 함수에 대한 참조를 얻는다.
 
3. RIL 데몬은 Vender RIL 함수들에 대한 하나의 참조를 제공하는 안드로이드 Telephony 스택상의  
    RIL_register를 호출한다.
 
RIL 상호작용
 
RIL 제어 관련 통신에는 두가지 형식이 존재한다.
 
Solicited commands : Solicited 명령어들은 전화걸기(DIAL) 과 HANGUP(전화끊기)와 같은 RIL 라이브러리에 의해
                                만들어 진다.
Unsolicited responses : Unsolicited responses는 CALL_STATE_CHNGED(전화 상태 변화)와 NEW_SMS(새 문자
                                   메시지)와 같은 baseband로 부터 만들어 진다.

 
Solicited
 
아래의 인용은 solicited 명령어들에 대한 인터페이스를 보여주고 있다.
 
void OnRequest (int request_id, void *data, size_t datalen, RIL_Token t);
void OnRequestComplete (RIL_Token t, RIL_Error e, void *response, size_t responselen);

 
그리고 아래와 같이 계열들로 묶여질 수 있는 60개 이상의 solicited 명령어들이 존재한다.
 
  • SIM PIN, IO, and IMSI/IMEI (11)
  • Call status and handling (dial, answer, mute…) (16)
  • Network status query (4)
  • Network setting (barring, forwarding, selection…) (12)
  • SMS (3)
  • PDP connection (4)
  • Power and reset (2)
  • Supplementary Services (5)
  • Vendor defined and support (4)
아래의 다이어그램은 안드로이드에서의 solicited call을 설명하고 있다.
 
 
 
Unsolicited
 
아래의 인용은 unsolicited 명령어들에 대한 인터페이스를 설명하고 있다.
 
void OnUnsolicitedResponse (int unsolResponse, void *data, size_t datalen);

 
그리고 아래와 같이 계열들로 묶여질 수 있는 10개 이상의 unsolicited 명령어들이 존재한다.
 
  • Network status changed (4)
  • New SMS notify (3)
  • New USSD notify (2)
  • Signal strength or time changed (2)
아래의 다이어그램은 안드로이드에서의 unsolicited call을 설명하고 있다.
 
 
 
RIL 구현하기
 
특정 radio RIL을 구현하기 위해서는, 라디오 요청을 처리하기 위해 안드로이드에서 요구되는 함수의 집합을 구현하는
공유 라이브러리를 만들어야 한다. 요구되는 함수들은 RIL header (/include/telephony/ril.h)에 정의된다.
 
안드로이드 radio 인터페이스는 radio-agnostic이며, Vender RIL은 radio를 통해 통신하기 위한 어떤 프로토콜도
사용할 수 있다. 안드로이드는 하나의 참조적 구현형태로써의 Vender RIL을 제공하고 있는데, 그것은 Hayes AT
command 집합을 사용하고 있으며, 여러분들은 telephony 테스트를 위한 쉬운 시작과 상업적 Vender RIL 들을 위한
가이드로써 사용할 수 있다. 참조적으로 구현된 RIL 소스 코드는 /commands/reference-ril/ 에서 볼 수 있다.
 
libril-<companyname>-<RIL version>.so 규약을 사용해서 공유 라이브러리 형태로 여러분의 Vender RIL을 컴파일
해라. 여기에 예로써, libril-acme-124.so가 있다.
  • libril: 모든 vender RIL 구현은 'libril' 로 시작
  • <companyname>: 특정 회사의 약어
  • <RIL version>: RIL 버전 숫자
  • so: 파일 확장자
RIL_Init
 
여러분의 Vender RIL은 모든 radio 요청들을 처리할 함수들에 대한 제어를 제공하는 RIL_Init 함수를 정의해야 한다.
RIL_Init은 RIL을 초기화하기 위해, 부트시점에서 안드로이드 RIL Daemon에 의해 호출된다.
 
RIL_RadioFunctions *RIL_Init (RIL_Env* env, int argc, char **argv);

 
RIL_Init은 radio 함수들에 대한 제어를 포함하는 RIL_RadioFuncions 구조체를 반환해야 한다.
 
type structure {
       int RIL_version;
       RIL_RequestFunc onRequest;
       RIL_RadioStateRequest onStateRequest;      
       RIL_Supports supports;
       RIL_Cancel onCancel;
       RIL_GetVersion getVersion;
}
RIL_RadioFunctions;

 
 
RIL 함수들
 
ril.h는 아래의 테이블에 설명된 함수들 같은, RIL_UNSOL_STK_CALL_SETUP, RIL_SIM_READY, RIL_SIM_NOT_READY 과
같은 RIL 상태들과 변수들을 정의한다. 더 상세하게는 헤더파일(/device/incldue/telephony/ril.h)을 살펴보길.
 
RIL Solicited 명령어 요청들.
 
Vender RIL은 solicited 명령어들을 처리하기 위해 아래의 테이블에 설명된 함수들을 제공해야 한다.
RIL solicited 명령어 요청 타입들은 RIL_REQUEST_ 라는 접두사를 가지고 ril.h에 정의된다.
상세하게는 헤더 파일을 체크하길.
 
함수명 설명
void (*RIL_RequestFunc) (int request, void *data, size_t datalen, RIL_Token t); 이것은 solicited 명령어들에 대한 시작 포인트이며, RIL_REQUST_ 접두사를 가지고 ril.h에 정의된 다양한 RIL solicited 요청 타입들을 제어할 수 있어야 한다.
  • request 는 RIL_REQUEST_* 중 하나임.
  • data 는 RIL_REQUST_* 위해 정의된 data에 대한 포인터임.
  • t 는 RIL_onResponse 에 수반되는 호출에서 사용되어야 함.
  • datalen 은 caller 소유이며, callee에 의해 수정되거나 free 되어서는 안됨.
RIL_onRequestComplete()에 대한 호출을 통해 완료되어야 함.
RIL_onRequestComplete()는 임의의 쓰레드로부터 이 함수의 반환 이전 또는 이후에 호출될 수 있다. 이것은 항상 동일한 쓰레드로부터 호출될 것이며, 그러므로 여기에서 반환이라함은 radio가 다른 명령을 수행할 준비하 되어있음을 의미한다.(이전 명령이 완료여부와 상관없이)
RIL_RadioState (*RIL_RadioStateRequest)(); 이 함수는 현재의 radio 상태를 동기적으로 반환해야 한다.
int (*RIL_Supports)(int requestCode); 이 함수는 명시된 RIL_REQUEST 코드가 지원된다면 "1"을 아니라면 "0"을 반환한다.
void (*RIL_Cancel)(RIL_Token t); 이 함수는 멈춰져 있는 요청을 취소시키기 위해 사용된다.
이 함수는 다른 쓰레드, 즉 RIL_RequestFunc 을 호출한 쓰레드가 아닌 쓰레드에 의해 호출된다.
 
취소시, callee는 요청을 포기하기 위해 최선을 다해야하며, 잠시후 RIL_Errno CALCELLED 를 가지고 RIL_onRequestComplete를 호출한다.
 
다른 결과들을 가진 이 요청들에 대한 RIL_onRequestComplete에 대한 수반되는 호출들은 묵인되지만, 무시된다.(그것은 취소 요청을 무시하기 위해 유효한 것이다)
 
RIL_Cancel 호출들은 즉시 반환되어야 하며, 취소를 기다려서는 안된다.
const char * (*RIL_GetVersion) (void); 여러분의 Vender RIL에 대한 버젼 문자열을 반환한다.
 
Vender RIL은 안드로이드 RIL 데몬에 역으로 통신하기 위해 다음과 같은 callback 메쏘드를 사용한다.
 
함수명 설명
void RIL_onRequestComplete(RIL_Token t, RIL_Errno e, void *response, size_t responselen);
  • t 는 이전 호출에서 RIL_Notification 루틴에 전달된 파라메터이다.
  • 만약 e != SUCCESS 라면, response 는 null 이 될것이며, 무시된다.
  • RIL_onRequestComplete 는 가능한 빨리 return 할 것이다.
void RIL_requestTimedCallback (RIL_TimedCallback callback, void *param, const struct timeval *relativeTime); RIL_RequestFunc 이 호출된 동일한 쓰레드에서 사용자 정의의 callback 함수를 호출한다. 만약 relativeTime 이 명시되었다면, 그것은 callback이 발생해야하는 상대적인 시각을 명시한다. 만약 relativeTime 이 NULL 이거나 0 으로 채워진 구조체에 대한 포인터라면, callback은 최대한 빨리 발생한다.

 
RIL Unsolicited 명령어들
 
아래의 테이블에 열거된 함수들은 안드로이드 플랫폼에서 unsolicited 명령어들을 발생시키기 위해 Vendor RIL에 의해
사용되는 call-back 함수들이다. 자세하게는 ril.h 를 보길.
 
함수명 설명
void RIL_onUnsolicitedResponse(int unsolResponse, const void *data, size_t datalen);
  • unsolResponse 는 RIL_UNSOL_RESPONSE_* 중 하나임.
  • data 는 RIL_UNSOL_RESPONSE_* 를 위해 정의된 data에 대한 포인터임.
  • data 는 caller 소유이며, callee 에 의해 수정되거나 free 되어서는 안됨.

이건 뭐 간단히 말해서 안드로이드 소프트웨어(Telephony service)와 하드웨어(Radio) 사이에 존재하는 놈(추상레이어)으로  인터페이스 역할을 한다.
  • Ex) SMS Sending/Receiving, Incomming/Outgoing call, Data, Network and so on.
  • 두가지 Command로 나눈다.

       1. Solicited : User가 요청한 command (SMS Sending, Outgoing call 등)

          - 101 개 정도 commands : (Ril_commands.h 에 정의)

       2. Unsolicited : User의 의도와 상관없이 network나 h/w에서 받는 command (SMS Retriving, Incomming call 등)

          - 31개 정도 (Ril_unsol_commands.h에 정의)

     

    getIMSI() : ril.java - {RIL_REQUEST_GET_IMSI, dispatchVoid, responseString}

    - dispatchVoid() : ril.cpp

    -- s_callbacks.onRequest(pRI->pCI->requestNumber, NULL, 0, pRI); //Vendor ril

    -- RIL_onRequestComplete : ril.cpp

    ---- responseFunction() : responseString()

    ---- sendResponse(p)

    - processResponse : ril.java

    processSolicited : ril.java

     

    Posted by jazzlife
    ,
     Complete End to End Call Flow of Short Message Service(SMS)

    [ad#co-1]

     We will use above picture as refference.

    For example,  Subscriber A(MS A) want to send Short message to subscriber B(MS B)

    1.  Then subscriber A will type the message on the phone and select subscriber B as the destination address.
    2.  After subsriber A, hit send button, MS terminal will request channel assignment to the BTS and BSC and then forward the MS A Information to MSC A
    3.  MSC A will check MS A(subscriber A) data from VLR, if the telecommunication operator has many SMSC, it will identified which SMSC this MS A belong to.
    4.  After that MS A will transfer the short message to MSC A, at this point on MS A phone will display “sending…” notification
    5.  MSC A routes the message to the interworking MSC(IW MSC), beside use IW MSC usually it can use STP
    6.  IW MSC will route the short message to the SMSC.
    7.  SMSC Send a notification report to IW MSC and then to MSC A, MSC B and come to subscriber. At this point MS A phone will display “Message Sent” but not yet delivered to MS B
    8.  All Above step called MO(Message Originating), we will come on MT(Message Terminating) on the next step
    9.  SMSC Transfer the short message to the Gateway MSC(GW MSC)
    10.  The GW MSC ask information from the HLR for routing the short message
    11.  GW MSC will forward the message to MSC B, and MSC B will check MS B data from VLR
    12.  MSC B Transfer the short message to MS B through BSC and BTS
    13.  MSC B Send delivery report to GW MSC, and GW MSC will forward to HLR and SMSC. At this point MS B receive the message and can read it.
    14.  Delivery report will send by SMSC to MS A after MS B receive the message.

    Quite log story  :) . but this simple thing need so many interworking between quite alot of telecommunication network element.

    'old > sms&mms' 카테고리의 다른 글

    The Radio Interface Layer (RIL)  (0) 2010.07.09
    Android's Radio Interface Layer(RIL)  (0) 2010.07.08
    Android SMS call analysis  (0) 2010.07.06
    기본 안드로이드 서비스 구조  (0) 2010.05.12
    SMS framework 소스 참고  (0) 2010.05.10
    Posted by jazzlife
    ,
    1. Core System services
    - Activity manager (manages application lifecycle)
    - Package manager (loads apk files)
    - Window manager (handles applications window manager interaction with surface flinger)
    - Resource manager (handles media resources)
    - Content providers (provides data to application)
    - View system (provides widgets, views, layouts to applications)

    2. Hardware services
    - Provides low-level access to hardware device
    - Location manager
    - Telephony manager
    - Bluetooth service
    - WiFi service
    - USB service
    - Sensor service

    http://www.linuxjournal.com/magazine/java-api-androids-telephony-stack?page=0,4&quicktabs_1=2

    http://sites.google.com/site/io/inside-the-android-application-framework

    http://www.netmite.com/android/mydroid/development/pdk/docs/telephony.html

    'old > sms&mms' 카테고리의 다른 글

    Complete End to End Call Flow of Short Message Service(SMS)  (0) 2010.07.08
    Android SMS call analysis  (0) 2010.07.06
    SMS framework 소스 참고  (0) 2010.05.10
    framework_source 참고  (0) 2010.05.10
    telephony framework architecture  (0) 2010.04.26
    Posted by jazzlife
    ,

    SMS 관련 소스


    packages/apps/IM/src/com/android/im/service/AndroidSmsService.java

    packages/apps/Mms/src/com/android/mms/transaction/SmsReceiverService.java


    frameworks/base/telephony/java/com/android/internal/telephony/gsm/SMSDispatcher.java

    frameworks/base/telephony/java/android/telephony/gsm/SmsManager.java

    frameworks/base/telephony/java/com/android/internal/telephony/gsm/SimSmsInterfaceManager.java

    frameworks/base/telephony/java/com/android/internal/telephony/gsm/RIL.java + 1076




    frameworks/base/core/java/android/provider/Telephony.java


    Telephony Class

    Sms Class

    Inbox Class

    Sent Class

    Draft Class

    OutBox Class

    Conversations Class

    Intents Class

    Threads Class

    Mms Class

    Inbox Class

    Sent Class

    Draft Class

    Outbox Class

    Addr Class

    Part Class

    Rate Class

    Intents Class

    MmsSms Class

    PendingMessages Class

    Carriers Class

    Intents Class


    Uri.parse

    content://sms

    content://sms/sent

    content://sms/draft

    content://sms/outbox

    content://sms/conversations

    content://mms-sms/threadID

    content://mms

    content://mms/inbox

    content://mms/sent

    content://mms/drafts

    content://mms/outbox

    content://mms-sms/

    content://mms-sms/conversations

    content://mms-sms/messages/byphone

    content://mms-sms/undelivered

    content://mms-sms/draft

    'old > sms&mms' 카테고리의 다른 글

    기본 안드로이드 서비스 구조  (0) 2010.05.12
    SMS framework 소스 참고  (0) 2010.05.10
    telephony framework architecture  (0) 2010.04.26
    3GPP Technical Specification Documents Download Site  (0) 2010.04.03
    Network switching subsystem  (0) 2010.03.24
    Posted by jazzlife
    ,

    'old > sms&mms' 카테고리의 다른 글

    SMS framework 소스 참고  (0) 2010.05.10
    framework_source 참고  (0) 2010.05.10
    3GPP Technical Specification Documents Download Site  (0) 2010.04.03
    Network switching subsystem  (0) 2010.03.24
    Definitions  (0) 2010.03.18
    Posted by jazzlife
    ,

    'old > sms&mms' 카테고리의 다른 글

    SMS framework 소스 참고  (0) 2010.05.10
    framework_source 참고  (0) 2010.05.10
    telephony framework architecture  (0) 2010.04.26
    Network switching subsystem  (0) 2010.03.24
    Definitions  (0) 2010.03.18
    Posted by jazzlife
    ,

    Network switching subsystem

    From Wikipedia, the free encyclopedia

      (Redirected from Home Location Register)
    Jump to: navigation, search

    Network switching subsystem (NSS) is the component of a GSM system that carries out switching functions and manages the communications between mobile phones and the Public Switched Telephone Network (PSTN). It is owned and deployed by mobile phone operators and allows mobile phones to communicate with each other and telephones in the wider telecommunications network. The architecture closely resembles a telephone exchange, but there are additional functions which are needed because the phones are not fixed in one location. Each of these functions handle different aspects of mobility management and are described in more detail below.

    The Network Switching Subsystem, also referred to as the GSM core network, usually refers to the circuit-switched core network, used for traditional GSM services such as voice calls, SMS, and circuit switched data calls.

    There is also an overlay architecture on the GSM core network to provide packet-switched data services and is known as the GPRS core network. This allows mobile phones to have access to services such as WAP, MMS, and Internet access.

    All mobile phones manufactured today have both circuit and packet based services, so most operators have a GPRS network in addition to the standard GSM core network.

    Contents

    [hide]

    [edit] Mobile switching center (MSC)

    [edit] Description

    The mobile switching center (MSC) is the primary service delivery node for GSM, responsible for routing voice calls and SMS as well as other services (such as conference calls, FAX and circuit switched data). The MSC sets up and releases the end-to-end connection, handles mobility and hand-over requirements during the call and takes care of charging and real time pre-paid account monitoring.

    In the GSM mobile phone system, in contrast with earlier analogue services, fax and data information is sent directly digitally encoded to the MSC. Only at the MSC is this re-coded into an "analogue" signal (although actually this will almost certainly mean sound encoded digitally as PCM signal in a 64-kbit/s timeslot, known as a DS0 in America).

    There are various different names for MSCs in different contexts which reflects their complex role in the network, all of these terms though could refer to the same MSC, but doing different things at different times.

    The gateway MSC (G-MSC) is the MSC that determines which visited MSC the subscriber who is being called is currently located. It also interfaces with the PSTN. All mobile to mobile calls and PSTN to mobile calls are routed through a G-MSC. The term is only valid in the context of one call since any MSC may provide both the gateway function and the Visited MSC function, however, some manufacturers design dedicated high capacity MSCs which do not have any BSSs connected to them. These MSCs will then be the Gateway MSC for many of the calls they handle.

    The visited MSC (V-MSC) is the MSC where a customer is currently located. The VLR associated with this MSC will have the subscriber's data in it.

    The anchor MSC is the MSC from which a handover has been initiated. The target MSC is the MSC toward which a Handover should take place. A mobile switching centre server is a part of the redesigned MSC concept starting from 3GPP Release 5.

    [edit] Mobile switching centre server (MSCS)

    The mobile switching centre server is a soft-switch variant of the mobile switching centre, which provides circuit-switched calling, mobility management, and GSM services to the mobile phones roaming within the area that it serves. MSS functionality enables split between control (signalling) and user plane (bearer in network element called as media gateway/MG), which guarantees more optimal placement of network elements within the network.

    MSS and MGW media gateway makes it possible to cross-connect circuit switched calls switched by using IP, ATM AAL2 as well as TDM. More information is available in 3GPP TS 23.205.

    [edit] Other GSM core network elements connected to the MSC

    The MSC connects to the following elements:

    [edit] Procedures implemented

    Tasks of the MSC include:

    • Delivering calls to subscribers as they arrive based on information from the VLR.
    • Connecting outgoing calls to other mobile subscribers or the PSTN.
    • Delivering SMSs from subscribers to the short message service centre (SMSC) and vice versa.
    • Arranging handovers from BSC to BSC.
    • Carrying out handovers from this MSC to another.
    • Supporting supplementary services such as conference calls or call hold.
    • Generating billing information.

    [edit] Home location register (HLR)

    The home location register (HLR) is a central database that contains details of each mobile phone subscriber that is authorized to use the GSM core network. There can be several logical, and physical, HLRs per public land mobile network (PLMN), though one international mobile subscriber identity (IMSI)/MSISDN pair can be associated with only one logical HLR (which can span several physical nodes) at a time.

    The HLR stores details of every SIM card issued by the mobile phone operator. Each SIM has a unique identifier called an IMSI which is the primary key to each HLR record.

    The next important items of data associated with the SIM are the MSISDNs, which are the telephone numbers used by mobile phones to make and receive calls. The primary MSISDN is the number used for making and receiving voice calls and SMS, but it is possible for a SIM to have other secondary MSISDNs associated with it for fax and data calls. Each MSISDN is also a primary key to the HLR record. The HLR data is stored for as long as a subscriber remains with the mobile phone operator.

    Examples of other data stored in the HLR against an IMSI record is:

    • GSM services that the subscriber has requested or been given.
    • GPRS settings to allow the subscriber to access packet services.
    • Current location of subscriber (VLR and serving GPRS support node/SGSN).
    • Call divert settings applicable for each associated MSISDN.

    The HLR is a system which directly receives and processes MAP transactions and messages from elements in the GSM network, for example, the location update messages received as mobile phones roam around.

    [edit] Other GSM core network elements connected to the HLR

    The HLR connects to the following elements:

    • The G-MSC for handling incoming calls
    • The VLR for handling requests from mobile phones to attach to the network
    • The SMSC for handling incoming SMS
    • The voice mail system for delivering notifications to the mobile phone that a message is waiting
    • The AUC for authentication and ciphering and exchange of data (triplets)

    [edit] Procedures implemented

    The main function of the HLR is to manage the fact that SIMs and phones move around a lot. The following procedures are implemented to deal with this:

    • Manage the mobility of subscribers by means of updating their position in administrative areas called 'location areas', which are identified with a LAC. The action of a user of moving from one LA to another is followed by the HLR with a Location area update procedure.
    • Send the subscriber data to a VLR or SGSN when a subscriber first roams there.
    • Broker between the G-MSC or SMSC and the subscriber's current VLR in order to allow incoming calls or text messages to be delivered.
    • Remove subscriber data from the previous VLR when a subscriber has roamed away from it.

    [edit] Authentication centre (AUC)

    [edit] Description

    The authentication centre (AUC) is a function to authenticate each SIM card that attempts to connect to the GSM core network (typically when the phone is powered on). Once the authentication is successful, the HLR is allowed to manage the SIM and services described above. An encryption key is also generated that is subsequently used to encrypt all wireless communications (voice, SMS, etc.) between the mobile phone and the GSM core network.

    If the authentication fails, then no services are possible from that particular combination of SIM card and mobile phone operator attempted. There is an additional form of identification check performed on the serial number of the mobile phone described in the EIR section below, but this is not relevant to the AUC processing.

    Proper implementation of security in and around the AUC is a key part of an operator's strategy to avoid SIM cloning.

    The AUC does not engage directly in the authentication process, but instead generates data known as triplets for the MSC to use during the procedure. The security of the process depends upon a shared secret between the AUC and the SIM called the Ki. The Ki is securely burned into the SIM during manufacture and is also securely replicated onto the AUC. This Ki is never transmitted between the AUC and SIM, but is combined with the IMSI to produce a challenge/response for identification purposes and an encryption key called Kc for use in over the air communications.

    [edit] Other GSM core network elements connected to the AUC

    The AUC connects to the following elements:

    • the MSC which requests a new batch of triplet data for an IMSI after the previous data have been used. This ensures that same keys and challenge responses are not used twice for a particular mobile.

    [edit] Procedures implemented

    The AUC stores the following data for each IMSI:

    • the Ki
    • Algorithm id. (the standard algorithms are called A3 or A8, but an operator may choose a proprietary one).

    When the MSC asks the AUC for a new set of triplets for a particular IMSI, the AUC first generates a random number known as RAND. This RAND is then combined with the Ki to produce two numbers as follows:

    • The Ki and RAND are fed into the A3 algorithm and the signed response (SRES) is calculated.
    • The Ki and RAND are fed into the A8 algorithm and a session key called Kc is calculated.

    The numbers (RAND, SRES, Kc) form the triplet sent back to the MSC. When a particular IMSI requests access to the GSM core network, the MSC sends the RAND part of the triplet to the SIM. The SIM then feeds this number and the Ki (which is burned onto the SIM) into the A3 algorithm as appropriate and an SRES is calculated and sent back to the MSC. If this SRES matches with the SRES in the triplet (which it should if it is a valid SIM), then the mobile is allowed to attach and proceed with GSM services.

    After successful authentication, the MSC sends the encryption key Kc to the base station controller (BSC) so that all communications can be encrypted and decrypted. Of course, the mobile phone can generate the Kc itself by feeding the same RAND supplied during authentication and the Ki into the A8 algorithm.

    The AUC is usually collocated with the HLR, although this is not necessary. Whilst the procedure is secure for most everyday use, it is by no means crack proof. Therefore a new set of security methods was designed for 3G phones.

    [edit] Visitor location register (VLR)

    [edit] Description

    The visitor location register is a temporary database of the subscribers who have roamed into the particular area which it serves. Each base station in the network is served by exactly one VLR, hence a subscriber cannot be present in more than one VLR at a time.

    The data stored in the VLR has either been received from the HLR, or collected from the MS. In practice, for performance reasons, most vendors integrate the VLR directly to the V-MSC and, where this is not done, the VLR is very tightly linked with the MSC via a proprietary interface.

    Data stored include:

    • IMSI (the subscriber's identity number).
    • Authentication data.
    • MSISDN (the subscriber's phone number).
    • GSM services that the subscriber is allowed to access.
    • access point (GPRS) subscribed.
    • The HLR address of the subscriber.

    [edit] Other GSM core network elements connected to the VLR

    The VLR connects to the following elements:

    • The V-MSC to pass needed data for its procedures; e.g., authentication or call setup.
    • The HLR to request data for mobile phones attached to its serving area.
    • Other VLRs to transfer temporary data concerning the mobile when they roam into new VLR areas. For example, the temporal mobile subscriber identity (TMSI).

    [edit] Procedures implemented

    The primary functions of the VLR are:

    • To inform the HLR that a subscriber has arrived in the particular area covered by the VLR.
    • To track where the subscriber is within the VLR area (location area) when no call is ongoing.
    • To allow or disallow which services the subscriber may use.
    • To allocate roaming numbers during the processing of incoming calls.
    • To purge the subscriber record if a subscriber becomes inactive whilst in the area of a VLR. The VLR deletes the subscriber's data after a fixed time period of inactivity and informs the HLR (e.g., when the phone has been switched off and left off or when the subscriber has moved to an area with no coverage for a long time).
    • To delete the subscriber record when a subscriber explicitly moves to another, as instructed by the HLR.

    [edit] Equipment identity register (EIR)

    The equipment identity register is often integrated to the HLR. The EIR keeps a list of mobile phones (identified by their IMEI) which are to be banned from the network or monitored. This is designed to allow tracking of stolen mobile phones. In theory all data about all stolen mobile phones should be distributed to all EIRs in the world through a Central EIR. It is clear, however, that there are some countries where this is not in operation. The EIR data does not have to change in real time, which means that this function can be less distributed than the function of the HLR. The EIR is a database that contains information about the identity of the mobile equipment that prevents calls from stolen, unauthorized or defective mobile stations. Some EIR also have the capability to log Handset attempts and store it in a log file.

    [edit] Other support functions

    Connected more or less directly to the GSM core network are many other functions.

    [edit] Billing centre (BC)

    The billing centre is responsible for processing the toll tickets generated by the VLRs and HLRs and generating a bill for each subscriber. It is also responsible for generating billing data of roaming subscriber.

    [edit] Short message service centre (SMSC)

    The short message service centre supports the sending and reception of text messages.

    [edit] Multimedia messaging service centre (MMSC)

    The multimedia messaging service centre supports the sending of multimedia messages (e.g., images, audio, video and their combinations) to (or from) MMS-enabled Handsets.

    [edit] Voicemail system (VMS)

    The voicemail system records and stores voicemails.

    [edit] Lawful interception functions

    According to U.S. law, which has also been copied into many other countries, especially in Europe, all telecommunications equipment must provide facilities for monitoring the calls of selected users. There must be some level of support for this built into any of the different elements. The concept of lawful interception is also known, following the relevant U.S. law, as CALEA. Generally Lawful Interception implementation is similar to the implementation of conference call. While A and B is talking with each other, C can join the call and listens silently.

    [edit] See also

    [edit] External links

    'old > sms&mms' 카테고리의 다른 글

    SMS framework 소스 참고  (0) 2010.05.10
    framework_source 참고  (0) 2010.05.10
    telephony framework architecture  (0) 2010.04.26
    3GPP Technical Specification Documents Download Site  (0) 2010.04.03
    Definitions  (0) 2010.03.18
    Posted by jazzlife
    ,

    Definitions

    old/sms&mms 2010. 3. 18. 15:53

    For the purposes of the present document, the following terms and definitions apply:

    NOTE 1:   The term "mobile station" (MS) in the present document is synonymous with the term "user equipment" (UE) in UMTS terminology as defined in 3GPP TR 21.905 [29].

    active MS: switched‑on mobile station with a SIM/UICC see 3GPP TS 31.101 [31] module attached

    alert‑SC: service element provided by a GSM/UMTS PLMN to inform an SC which has previously initiated unsuccessful short message delivery attempt(s) to a specific MS, that the MS is now recognized by the PLMN to have recovered operation

    status report: SC informing the originating MS of the outcome of a short message submitted to an SME

    Gateway MSC For Short Message Service (SMS‑GMSC): function of an MSC capable of receiving a short message from an SC, interrogating an HLR for routing information and SMS info, and delivering the short message to the VMSC or the SGSN of the recipient MS

    Interworking MSC For Short Message Service (SMS‑IWMSC): function of an MSC capable of receiving a short message from within the PLMN and submitting it to the recipient SC

    IP-Short-Message-Gateway (IP-SM-GW): function responsible for protocol interworking between the IP-based UE and the SC

    Messages‑Waiting (MW): ervice element that makes a PLMN store information (Messages‑Waiting‑Indication), listing those SCs that have made unsuccessful short message delivery attempts to MSs in that PLMN

    Messages‑Waiting‑Indication (MWI): data to be stored in the HLR and VLR with which an MS is associated, indicating that there is one or more messages waiting in a set of SCs to be delivered to the MS (due to unsuccessful delivery attempt(s))

    Messages‑Waiting‑Data (MWD): part of the MWI to be stored in the HLR. MWD consists of an address list of the SCs which have messages waiting to be delivered to the MS

    Mobile-services Switching Centre (MSC): exchange which performs switching functions for mobile stations located in a geographical area designated as the MSC area

    Mobile‑Station‑Memory‑Capacity‑Exceeded‑Flag (MCEF): part of the MWI to be stored in the HLR

    NOTE 2:   MCEF is a Boolean parameter indicating if the address list of MWD contains one or more entries because an attempt to deliver a short message to an MS has failed with a cause of MS Memory Capacity Exceeded

    Mobile‑Station‑Not‑Reachable‑Flag (MNRF): part of the MWI to be stored in the VLR and the HLR

    NOTE 3:   MNRF is a Boolean parameter indicating if the address list of MWD contains one or more entries because an attempt to deliver a short message to an MS has failed with a cause of Absent Subscriber.

    Mobile‑station‑Not-Reachable-for-GPRS (MNRG): part of the MWI to be stored in the SGSN and the HLR

    NOTE 4:   MNRG is a Boolean parameter indicating if the address list of MWD contains one or more entries because an attempt to deliver a short message to an MS has failed with a cause of Absent Subscriber.

    Mobile‑Station‑Not‑Reachable-via-the-MSC-Reason (MNRR-MSC): part of the MWI in the HLR which stores the reason for an MS being absent when an attempt to deliver a short message to an MS fails at the MSC with a cause of Absent Subscriber

    Mobile‑Station‑Not‑Reachable-via-the-SGSN-Reason (MNRR-SGSN): part of the MWI in the HLR which stores the reason for an MS being absent when an attempt to deliver a short message to an MS fails at the SGSN with a cause of Absent Subscriber

    More‑Messages‑To‑Send (MMS): information element offering an MS receiving a short message from an SC the information whether there are still more messages waiting to be sent from that SC to the MS

    NOTE 5:   The TP‑MMS element (conveyed in the Transfer layer) is copied into the RP‑MMS element (conveyed in the Relay layer). It is possible with Phase 2 and later versions of MAP (3GPP TS 29.002 [15]) for the RP‑MMS element to keep an SM transaction open between the SMS-GMSC and the MS in the case where there are more‑messages‑to‑send. Earlier versions of MAP support the transport of the TP‑MMS element.

    priority: service element enabling the SC or SME to request a short message delivery attempt to an MS irrespective of whether or not the MS has been identified as temporarily absent

    protocol‑identifier: information element by which the originator of a short message (either an SC or an MS) may refer to a higher layer protocol

    receiving MS: the mobile station to which an MT SM is destined.

    reply path procedure: mechanism which allows an SME to request that an SC should be permitted to handle a reply sent in response to a message previously sent from that SME to another SME

    NOTE 6:   This may happen even though the SC may be unknown to the SME which received the initial message.

    report: response from either the network or the recipient upon a short message being sent from either an SC or an MS

    NOTE 7:   A report may be a delivery report, which confirms the delivery of the short message to the recipient, or it may be a failure report, which informs the originator that the short message was never delivered and the reason why.

          When issued by the Service Centre, the delivery report confirms the reception of the Short Message by the SC, and not the delivery of the Short Message to the SME.

          When issued by the Mobile Station, the delivery report confirms the reception of the Short Message by the Mobile Station, and not the delivery of the Short Message to the user.

    replace short message type: range of values in the Protocol Identifier which allows an indication to be sent with a short message (MT or MO) that the short message is of a particular type allowing the receiving MS or the SC to replace an existing message of the same type held in the SC, the ME or on the SIM/UICC, provided it comes:

         in MT cases:                 from the same SC and originating address;

         in MO cases:                 from the same MS.

    sending MS: the mobile station from which an MO SM is sourced.

    Service Centre (SC): function responsible for the relaying and store‑and‑forwarding of a short message between an SME and an MS

    NOTE 8:   The SC is not a part of the GSM/UMTS PLMN, however MSC and SC may be integrated.

    Serving GPRS Support Node (SGSN): exchange which performs packet switching functions for mobile stations located in a geographical area designated as the SGSN area

    short message: information that may be conveyed by means of the Short Message Service

    NOTE 9:   As described in the present document.

    Short Message Entity (SME): entity which may send or receive Short Messages

    NOTE 10: The SME may be located in a fixed network, an MS, or an SC.

    SMS‑STATUS‑REPORT: short message transfer protocol data unit informing the receiving MS of the status of a mobile originated short message previously submitted by the MS, i.e. whether the SC was able to forward the message or not, or whether the message was stored in the SC for later delivery

    SMS‑COMMAND: short message transfer protocol data unit which enables an MS to invoke an operation at the SC

    NOTE 11: An MS may then, for example, delete a short message, cancel a TP-Status-Report-Request, enquire about the status of a short message or request another function to be performed by the SC.

    NOTE 12: The type of operation is indicated by the TP‑Command‑Type and the particular SM to operate on is indicated by the TP‑Message‑Number and the TP‑Destination‑Address. Receipt of an SMS‑COMMAND is confirmed by an RP‑ACK or RP‑ERROR. In the case of certain SMS‑COMMANDs, an SMS‑STATUS‑REPORT may be sent, where the outcome of the SMS‑COMMAND is passed in its TP‑Status field.

    SMS‑DELIVER: short message transfer protocol data unit containing user data (the short message), being sent from an SC to an MS

    SMS‑SUBMIT: short message transfer protocol data unit containing user data (the short message), being sent from an MS to an SC

    Service‑Centre‑Time‑Stamp (SCTS): information element offering the recipient of a short message the information of when the message arrived at the SM‑TL entity of the SC

    NOTE 13: The time of arrival comprises the year, month, day, hour, minute, second and time zone.

    UE‑Not-Reachable-for-IP (UNRI): part of the MWI to be stored in the IP-SM-GW and the HSS/HLR

    NOTE 14: UNRI is a Boolean parameter indicating if the address list of MWD contains one or more entries because an attempt to deliver a short message to an UE has failed with a cause of Absent Subscriber.

    UE‑Not‑Reachable-Reason (UNRR): part of the MWI in the HSS/HLR which stores the reason for an UE being absent when an attempt to deliver a short message to an UE fails at the IP-SM-GW.

    Validity‑Period (VP): information element enabling the originator MS to indicate the time period during which the originator considers the short message to be valid.

    Visitor Location Register (VLR) is a database - part of the GSM mobile phone system - which stores information about all the mobiles that are currently under the jurisdiction of the MSC (Mobile Switching Center) which it serves. Of all the information it stores about each MS (Mobile Station), the most important is the current LAI (Location Area Identity). LAI identifies under which BSC (Base Station Controller) the MS is currently present. This information is vital in the call setup process.

    Whenever an MSC detects a new MS in its network, in addition to creating a new record in the VLR, it also updates the HLR of the mobile subscriber, apprising it of the new location of that MS.


    3rd Generation Partnership Project (3GPP)
    Technical Specification (TS)
    Short Message Service (SMS)
    Public Land Mobile Network (PLMN)
    Operator Determined Barring (ODB)
    Cell Broadcast Service (CBS)
    Service Centre(s) (SC)
    Mobile‑services Switching Centre(s) (MSC)
    Point-to-Point (PP)
    Short Message Service (SMS)
    Data Terminal Equipment ‑ Data Circuit terminating Equipment (DTE ‑ DCE)
    Mobile Application Part (MAP)
    Subscriber Identity Module ‑ Mobile Equipment (SIM‑ ME)
    Universal Multiple‑Octet Coded Character Set (USC)
    Personalisation of Mobile Equipment (ME)
    General Packet Radio Service (GPRS)
    Ir Mobile Communications (IrMC)
    Internet Mail Consortium (IMC)
    Session Initiation Protocol (SIP)
    mobile station" (MS)

    'old > sms&mms' 카테고리의 다른 글

    SMS framework 소스 참고  (0) 2010.05.10
    framework_source 참고  (0) 2010.05.10
    telephony framework architecture  (0) 2010.04.26
    3GPP Technical Specification Documents Download Site  (0) 2010.04.03
    Network switching subsystem  (0) 2010.03.24
    Posted by jazzlife
    ,