Android: How to get Call Log (통화목록 가져오기)

1. Permission

    <uses-permission android:name="android.permission.READ_CONTACTS" />
    <uses-permission android:name="android.permission.READ_CALL_LOG" />      
    <uses-permission android:name="android.permission.WRITE_CALL_LOG" />

2. Source

public class MainActivity extends Activity {
   
    public static final String MESSAGE_TYPE_INBOX = "1";
    public static final String MESSAGE_TYPE_SENT = "2";
    public static final String MESSAGE_TYPE_CONVERSATIONS = "3";
    public static final String MESSAGE_TYPE_NEW = "new";

    final static private String[] CALL_PROJECTION = { CallLog.Calls.TYPE,
                                                      CallLog.Calls.CACHED_NAME, CallLog.Calls.NUMBER,
                                                      CallLog.Calls.DATE,        CallLog.Calls.DURATION };
   
    private static final String TAG = "Victor-Manage_Clique";

    private Cursor getCallHistoryCursor(Context context) {
        Cursor cursor = context.getContentResolver().query(
                                                CallLog.Calls.CONTENT_URI, CALL_PROJECTION,
                                                null, null, CallLog.Calls.DEFAULT_SORT_ORDER);      
        return cursor;
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
       
        callLog();

    }

    private void callLog() {
        int callcount = 0;
        String callname = "";
        String calltype = "";
        String calllog = "";
        Cursor curCallLog = getCallHistoryCursor(this);
        Log.i( TAG , "processSend() - 1");
        // Log.i( TAG , "curCallLog: " + curCallLog.getCount());
        if (curCallLog.moveToFirst() && curCallLog.getCount() > 0) {
            while (curCallLog.isAfterLast() == false) {
                 StringBuffer sb = new StringBuffer();

                if (curCallLog.getString(curCallLog
                        .getColumnIndex(CallLog.Calls.TYPE)).equals(MESSAGE_TYPE_INBOX)){
                    calltype = "수신";
                }
                else if (curCallLog.getString(curCallLog
                        .getColumnIndex(CallLog.Calls.TYPE)).equals(MESSAGE_TYPE_SENT)){
                    calltype = "발신";                  
                }
                else if (curCallLog.getString(curCallLog
                        .getColumnIndex(CallLog.Calls.TYPE)).equals(MESSAGE_TYPE_CONVERSATIONS)){
                    calltype = "부재중";                  
                }
               
                if (curCallLog.getString(curCallLog
                        .getColumnIndex(CallLog.Calls.CACHED_NAME)) == null) {
                    callname = "NoName";
                }
                else {
                    callname = curCallLog.getString(curCallLog
                            .getColumnIndex(CallLog.Calls.CACHED_NAME));
                }
                sb.append(timeToString(curCallLog.getLong(curCallLog
                        .getColumnIndex(CallLog.Calls.DATE))));
                sb.append("\t").append(calltype);
                sb.append("\t").append(callname);
                sb.append("\t").append(curCallLog.getString(curCallLog.getColumnIndex(CallLog.Calls.NUMBER)));
                curCallLog.moveToNext();
               
                String backupData = sb.toString();
             
                callcount++;
                Log.i("call history[", sb.toString());
            }
        }
    }

    private String timeToString(Long time) {
        SimpleDateFormat simpleFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
        String date = simpleFormat.format(new Date(time));
        return date;
    }  
}

GSM 7Bit Table with UCS2 value

UCS2 0x82 Encoding

The encoding for '0x82' format is as follow

   1. The first octet is '0x82'

   2. The second octet is the number of UCS2 characters

   3. The third octet and fourth octet is full 16-bit Base Pointer for the UCS2

   4. The following octets are the coded characters with the following rule:

     - If the MSB (most significant bit) is zero, 
       the remaining 7 bits contain GSM Default Alphabet.

     - If the MSB is one, the remaining 7 bits are offset value added to Base Pointer 
       which the result defines the UCS2 character.

Example:
We have 3 UCS2: Sকদ
The characters in bytes are: '0x0053' for "S", '0x0995' for "ক", and '0x09A6' for "দ".
The coding for Alpha field for this format is: '82 03 09 95 53 80 91'.

How can we get that value?
The first octet and second octet is quite clear.
For the third and fourth octet, the Base Pointer, we can get it from the lowest value from all UCS characters. Of course, it is better if we have the UCS2 characters look-up table which indicates the Base Pointer for each specific set.

In this example, I set the Base Pointer as '0x0995'.
The fifth octet is the character "S" ('0x0053').

Since it is default alphabet, then the octet value is '0x53'.

The sixth octet is the character "ক" ('0x0995'). 
To encode this character, we calculate the additional offset from the Base Pointer.
Additional value = '0x0995' - '0x0995' = '0x00' = 000 0000 (only 7 bit)
The coded character has MSB set to 1. Hence the value is (1000 0000) = '0x80'.

The seventh octet is the character for "দ" ('0x09A6').
Additional value = 0x'09A6' - '0x0995' = '0x11' = 001 0001 (only 7 bit)
The coded character has MSB set to 1. Hence the value is (1001 0001)b = '0x91'.

UCS2 0x81 Encoding

The encoding for '81' format is as follow
   1. The first octet is '0x81'
   2. The second octet is the number of UCS2 characters
   3. The third octet is Base Pointer for bit15 to bit8 for the UCS2: 0xxxxxxxx0000000
   4. The following octets are the coded characters with the following rule: 
        - If the MSB (most significant bit) is zero, 
          the remaining 7 bits contain GSM Default Alphabet.
        - If the MSB is one, the remaining 7 bits are offset value added to Base Pointer 
          which the result defines the UCS2 character.

Example:
We have 3 UCS2: Sকদ
The characters in bytes are: '0x0053' for "S", '0x0995' for "ক", and '0x09A6' for "দ".
The coding for Alpha field for this format is: '81 03 13 53 95 A6'.

How can we get that value?
First, the first octet is '0x81'.
The second octet shall be '03' since we have 3 UCS2.
The third octet is the Base Pointer. If we look at all UCS2 characters which high byte (two first digits) is not '00', then we get '0995' and '09A6'. In binaries we get:
                16                           1 (bit position)
     '0995' = 0000 1001 1001 0101
     '09A6' = 0000 1001 1010 0110

     >> 0000 1001 1000 0000 : Base pointer '0980' coded as '0x13'
So, the Base pointer value is 0001 0011 or '0x13'.
The fourth octet is the first character "S".

Since it is default alphabet, we simply set bit 7 with zero, and get 7-bits of "S":
"S" = '0053' = 0000 0000 0101 0011                                    (0 + 1010011) = 0101 0011 = '53'
TIPS: when you get '00XX', then the octet is always the low byte XX.

The fifth octet is for character "ক" ('0x0995').
To encode this character, we calculate the additional offset from the Base Pointer.
Additional value = '0x0995' - '0x0980' = '0x15' = 001 0101 (only 7 bit)
The coded character has MSB set to 1. Hence the value is (1001 0101) = '0x95'.

The sixth octet is the character for "দ" ('0x09A6').
By doing the same way as fifth octet, we get '0xA6'.

UCS2 0x80 Encoding

The encoding for '0x80' format is as follow:
   1. the first octet/byte is '0x80'
   2. The following octets are the 16 bit UCS characters, Little Endian format.

Example:

 We have 3 UCS2: Sকদ

The characters in bytes are: '0053' for "S", '0995' for "ক", and '09A6' for "দ".
The coding for Alpha field for this format is: '80 0053 0995 09A6'.

UCS2 Format (Kind of UCS2)

	Octet/Byte number
	1	2	3	4	5	6	7
Format 1	0x80	Char1	Char1	Char2	Char2	...	...
Format 2	0x81	N	BP	Char1	Char2	...	...
Format 3	0x82	N	BP	BP	Char1	Char2	...

There are 3 kinds of format used by SIM to display UCS2.

N   : Count

BP : Base Point

Which one to choose: 'UCS 0x80', 'UCS 0x81', or 'UCS 0x82'?

Step1. Whenever possible, use '0x81' format.

      Strong point  : '0x81' offers smallest number of memory required, 
                           i.e. (3 + N) bytes. 

      Weak point    : this format only works for character set containing 128 characters 
                            that lies between 'XX00' to 'XX7F', or between 'XX80' to 'XXFF'.

Step2. If '0x81' is impossible, try the '0x82' format

      Strong point  : '0x82' offers slightly bigger number of memory required compared

                           to '0x81' format,

                           i.e. (4 + N) bytes

      Weak point    : this format only works for character set containing 128 characters

Step3. If '0x81' and '0x82' is not possible, you must use '0x80'

      Strong point  : '0x80' can cover all UCS2 range from '0000' to 'FFFF'

      Weak point    : the number of bytes required is large, i.e. (1 + 2 * N) bytes

WCDMA/UMTS: Specification

u Specifications are segmented by layers and  available on the ftp site:

    http://www.3gpp.org/specification-numbering

u  For a complete list of Release 99 specifications see 21.101.

     http://www.3gpp.org/ftp/Specs/html-info/21101.htm

u  For a list of acronyms, see 21.905.

     http://www.3gpp.org/ftp/Specs/html-info/21905.htm

u  25 Series – Segment for technique description

     http://www.3gpp.org/ftp/Specs/html-info/25-series.htm

21.905       Vocabulary for 3GPP Specifications

24.007       Mobile radio interface signaling layer 3; General Aspects

24.008       Mobile radio Layer 3 specification; Core network protocols; Stage 3

25.211       Physical channels and mapping of transport channels onto physical channels (FDD)

25.301       Radio Interface Protocol Architecture

25.321       Medium Access Control (MAC) protocol

25.322       Radio Link Control (RLC) protocol

25.331       Radio Resource Control (RRC) protocol

25.101       UE Radio transmission and reception (FDD)

25.104       UTRA (BS) FDD; Radio transmission and reception

25.213       Spreading and modulation (FDD)

25.302       Services provided by the physical layer

25.331       Radio Resource Control (RRC) protocol

WCDMA/UMTS - WCDMA UE Call State

UMTS 3GPP Main Feature

< Release 7 >

• Higher Order Modulation (DL 64 QAM, UL 16 QAM)
• CPC (Continous Packet Connectivity, TDX + DRX)
• Enhanced F-DPCH
• Improved L2 (for Higher downlink data rate)
• Enhanced Cell_FACH for downlink
• Downlink MIMO

< Release 8 >

• Dual Cell HSDPA
• Combination of 64 QAM and MIMO
• Improved L2 (for Higher uplink data rate)
• Enhanced Cell_FACH for uplink
• CS over HSPA
• Serving Cell Change Enhancement
• HS-DSCH Reception in Cell FACH

< Release 9 >

• Dual Cell HSUPA
• Dual Band HSDPA
• Dual Cell HSDPA + MIMO
• 2ms TTI Uplink range extension

< Release 10 >

• Four Carrier HSDPA

MediaTek to announce an octa-core LTE chipset in January

MediaTek (MTK) recently announced its first true-octa core processor, as part of the MT6592 chipset.

 The successor of this SoC is allegedly in the works and the upcoming chip that is reportedly known as MT6595 is rumored to go official in the January, next year.

The company's upcoming chipset is basically an LTE enabled version of the MT6592 and is very likely to keep the true octa-core CPU. If the rumors turn out correct, MediaTek will be looking to expand its market share even further in 2014.

Until now, MediaTek has been producing chipsets, which are ideal for mid-range and budget friendly smartphones. However, things might soon change for the Taiwanese semi-conductor company and we really hope the company rises its game and poses a more serious threat to Qualcomm (QCT) and lightens up the development race.

Reference :
http://www.gsmarena.com/mediatek_to_announce_its_first_lte_enabled_chipset_in_january-news-7344.php

MediaTek 4G/LTE samples delivered to customers

Another octa-core?  MediaTek is going from strength to strength and it seems poised to end the year on a high note. According to Digitimes, the outfit has already delivered its first LTE samples to potential clients for verification.

As we reported on multiple occasions, MediaTek is planning to ship its first LTE application processors in early 2014 and if this latest report is true, we could be looking at a Q1 launch. MediaTek is expected to formally announce its first chip by the end of the year, but this is more of a PR gesture, a way of telling investors that the first LTE chip was ready in Q4 2013.

However, it remains unclear what sort of samples were shipped. Earlier this week it was reported that MediaTek’s first LTE-enabled SoC will be a version of the MT6592 octa-core, based on ARM’s Cortex A7 processor cores and Mali-450 graphics.

Digitimes is referring to the chip as the MT6590, while other sources have mentioned yet another version, the MT6595. One explanation is that it is the exact same chip and that someone simply got it wrong, but it is also possible that there are two or more different variants in the works.

The MT6590 is said to support five modes and ten frequency bands. This is not on par with LTE solutions from Qualcomm and Broadcom though, but MediaTek is going after different markets, namely Asia.

Reference : http://www.fudzilla.com/home/item/33478-mediatek-4g-lte-samples-delivered-to-customers

CES: MediaTek mobile apps processor has 12 ARM cores (MT6592)

CES takes place in Las Vegas next month (7-10 January) and in the run up to the consumer electronics event MediaTek is showing its first true octa-core mobile system on a chip (SOC) which integrates an eight-core application processor.

It also integrates an ARM Mali quad-core graphics processor.

The MT6592 is the next step up from MediaTek’s quad-core mobile platforms, and is expected to be available in devices running Android ‘Jelly Bean’ by the end of 2013.

It is also expected to be used in mobile devices running Android ‘Kit-Kat’ early in 2014.

The 28nm MT6592 has eight ARM Cortex-A7 CPU cores, each capable of clock speeds up to 2GHz. The true octa-core architecture is scalable, and implements combinations of the cores to support lower power applications and well as full performance video applications.

The chip integrates an ARM Mali quad-core graphics engine supporting Ultra-HD 4Kx2K H.264 video playback and support for new video codecs such as H.265 and VP9, a 16-megapixel camera and a Full HD display.

It also supports automatic frame-rate conversion of standard 24/30fps video to high-quality 60fps video for significantly smoother playback.

There are interfaces for dual-band 801.11n Wi-Fi, Miracast screen-sharing as well as Bluetooth, GPS and an FM tuner.





- See more at: http://www.electronicsweekly.com/news/components/microprocessors-and-dsps/ces-mediatek-mobiel-apps-processor-has-12-arm-cores-2013-12/#sthash.XZo8G0Qs.dpuf

Android: How to use Edittext in android

- JAVA 

public class Ex03_EditTextActivity extends Activity implements OnClickListener {
    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
       
        Button button = (Button)this.findViewById(R.id.Button1);
        button.setOnClickListener(this);
        Button button1 = (Button)this.findViewById(R.id.Button2);
        button1.setOnClickListener(this);
    }

 @Override
 public void onClick(View arg0) {
  // TODO Auto-generated method stub
  EditText editText = (EditText)this.findViewById(R.id.Edit1);
  TextView textView = (TextView)this.findViewById(R.id.TextView1);
 
  switch(arg0.getId()){
  case R.id.Button1: // Input text to textView from editText
   String al1 = editText.getText().toString();
   textView.setText(al1);
   break;
  
  case R.id.Button2: // Clear All
   editText.setText("");
   textView.setText("");
   break;
  }
 }
}

-xml 소스
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:orientation="vertical" >
    <TextView
        android:layout_width="fill_parent"
        android:layout_height="wrap_content" />
    <TextView
        android:id="@+id/TextView1"
        android:layout_width="fill_parent"
        android:layout_height="wrap_content"
        android:text="글자를 Edit에 치세요" />
    <EditText
        android:id="@+id/Edit1"
        android:layout_width="fill_parent"
        android:layout_height="wrap_content"
        android:hint="글자를 입력하세요" />
    <Button
        android:id="@+id/Button1"
        android:layout_width="fill_parent"
        android:layout_height="wrap_content"
        android:text="click" />
    <Button
        android:id="@+id/Button2"
        android:layout_width="fill_parent"
        android:layout_height="wrap_content"
        android:text="clear" />
</LinearLayout>


- Display
   

Android: How to use Listview in android

public class MainActivity extends Activity {
    String[] mData = {"A", "B", "C", "D"};
 
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main_activity);
 

        ListView mListView = (ListView) findViewById(R.id.list);
        ArrayAdapter adapter 

              = new ArrayAdapter<String>(this, android.R.layout.simple_list_item_1, mData);
        mListView .setAdapter(adapter);
    }
}

Voice over LTE - VoLTE

What is VoLTE? 

 Operation of Voice over LTE(VoLTE) system for providing a unified format of voice traffic on LTE, and other systems including CSFB (Circuit Switched Fall Back), and SV-LTE(Simultaneous Voice & LTE).
This approach is based on the IP Multimedia Subsystem (IMS) network, with specific profiles for control and media planes of voice service on LTE defined by GSMA in PRD IR.92. This approach results in the voice service (control and media planes) being delivered as data flows within the LTE data bearer. This means that there is no dependency on (or ultimately, requirement for) the legacy Circuit Switch voice network to be maintained.

• Circuit-switched fallback (CSFB)|
  In this approach, LTE just provides data services, and when a voice call is to be initiated or received, it will fall back to the circuit switched domain. When using this solution, operators just need to upgrade the MSC instead of deploying the IMS, and therefore, can provide services quickly. However, the disadvantage is longer call setup delay.
• Simultaneous voice and LTE (SVLTE)
  In this approach, the handset works simultaneously in the LTE and circuit switched modes, with the LTE mode providing data services and the circuit switched mode providing the voice service. This is a solution solely based on the handset, which does not have special requirements on the network and does not require the deployment of IMS either. The disadvantage of this solution is that the phone can become expensive with high power consumption.

Issues for Voice services over LTE
 Unlike previous cellular telecommunications standards including GSM, LTE does not have dedicated channels for circuit switched telephony. Instead LTE is an all-IP system providing an end-to-end IP connection from the mobile equipment to the core network and out again.
 In order to provide some form of voice connection over a standard LTE bearer, some form of Voice over IP, VoIP must be used.
 The aim for any voice service is to utilise the low latency and QoS features available within LTE to ensure that any voice service offers an improvement over the standards available on the 2G and 3G networks.
 However to achieve a full VoIP offering on LTE poses some significant problems which will take time to resolve. With the first deployments having taken place in 2010, it is necessary that a solution for voice is available within a short timescale.

Reference : 

http://www.radio-electronics.com/info/cellulartelecomms/lte-long-term-evolution/voice-over-lte-volte.php

http://en.wikipedia.org/wiki/Voice_over_LTE#Voice_calls

Linux: How to install XRDP (Ubuntu)

If you wanna do remote control your LINUX server by using the Laptop.

You can use the XRDP.

sudo apt-get install xrdp
dpkg –l| grep xrdp
   xrdp 0.5.0~20100303cvs-4 Remote Desktop Protocol (RDP) serve
sudo iptables –L | grep LISTEN
sudo su -
service xrdp start

GSM/UMTS/LTE : Cause values for call control

1          Normal class

1.1          Cause No. 1 "unassigned (unallocated) number"

This cause indicates that the destination requested by the mobile station cannot be reached because, although the number is in a valid format, it is not currently assigned (allocated).

1.2          Cause No. 3 "no route to destination"

This cause indicates that the called user cannot be reached because the network through which the call has been routed does not serve the destination desired.

1.3          Cause No. 6 "channel unacceptable"

This cause indicates the channel most recently identified is not acceptable to the sending entity for use in this call.

1.4          Cause No. 8 "operator determined barring"

This cause indicates that the MS has tried to access a service that the MS's network operator or service provider is not prepared to allow.

1.5          Cause No.16 "normal call clearing"

This cause indicates that the call is being cleared because one of the users involved in the call has requested that the call be cleared.

Under normal situations, the source of this cause is not the network.

1.6          Cause No.17 "user busy"

This cause is used when the called user has indicated the inability to accept another call.

It is noted that the user equipment is compatible with the call.

1.7          Cause No. 18 "no user responding"

This cause is used when a user does not respond to a call establishment message with either an alerting or connect indication within the prescribed period of time allocated (defined by the expiry of either timer T303 or T310).

1.8          Cause No. 19 "user alerting, no answer"

This cause is used when a user has provided an alerting indication but has not provided a connect indication within a prescribed period of time.

1.9          Cause No. 21 "call rejected"

This cause indicates that the equipment sending this cause does not wish to accept this call, although it could have accepted the call because the equipment sending this cause is neither busy nor incompatible.

1.10       Cause No. 22 "number changed"

This cause is returned to a calling mobile station when the called party number indicated by the calling mobile station is no longer assigned. The new called party number may optionally be included in the diagnostic field. If a network does not support this capability, cause No. 1 "unassigned (unallocated) number" shall be used.

1.11       Cause No. 24 "call rejected due to feature at the destination"

This cause is returned when the call is rejected due to a feature at the destination, e.g. Anonymous Call Rejection.
This cause is only generated by the network. This cause is not generated by the MS.

1.12       Cause No. 25 "pre-emption"

This cause is returned to the network when a mobile station clears an active call which is being pre-empted by another call with higher precedence.

1.13       Cause No. 26 "non-selected user clearing"

Not supported. Treated as cause #31.

1.14       Cause No. 27 "destination out of order"

This cause indicates that the destination indicated by the mobile station cannot be reached because the interface to the destination is not functioning correctly. The term "not functioning correctly" indicates that a signaling message was unable to be delivered to the remote user; e.g., a physical layer or data link layer failure at the remote user, user equipment off-line, etc.

1.15       Cause No. 28 "invalid number format (incomplete number)"

This cause indicates that the called user cannot be reached
because the called party number is not a valid format or is not complete.

1.16       Cause No. 29 "facility rejected"

This cause is returned when a facility requested by user can not be provided by the network.

1.17       Cause No. 30 "response to STATUS ENQUIRY"

This cause is included in STATUS messages if the message is sent in response to a STATUS ENQUIRY message.

1.18       Cause No. 31 "normal, unspecified"

This cause is used to report a normal event only when no other cause in the normal class applies.

2          Resource Unavailable Class

2.1          Cause No. 34 "no circuit/channel available"

This cause indicates that there is no appropriate circuit/channel presently available to handle the call.

2.2          Cause No. 38 "network out of order"

This cause indicates that the network is not functioning correctly and that the condition is likely to last a relatively long period of time;

e.g., immediately re-attempting the call is not likely to be successful.

2.3          Cause No. 41 "temporary failure"

This cause indicates that the network is not functioning correctly and that the condition is not likely to last a long period of time;

e.g., the mobile station may wish to try another call attempt almost immediately.

2.4          Cause No. 42 "switching equipment congestion"

This cause indicates that the switching equipment generating this cause is experiencing a period of high traffic.

2.5          Cause No. 43 "access information discarded"

This cause indicates that the network could not deliver access information to the remote user as requested;
i.e., a user-to-user information, low layer compatibility, high layer compatibility, or sub-address as indicated in the diagnostic.
It is noted that the particular type of access information discarded is optionally included in the diagnostic.

2.6          Cause No. 44 "requested circuit/channel not available"

This cause is returned when the circuit or channel indicated by the requesting entity cannot be provided by the other side of the interface.

2.7          Cause No. 47 "resource unavailable, unspecified"

This cause is used to report a resource unavailable event only when no other cause in the resource unavailable class applies.

3          Service or Option not available Class

3.1          Cause No. 49 "quality of service unavailable"

This cause indicates to the mobile station that the requested quality of service,
as defined in ITU-T Recommendation X.213 [144], cannot be provided.

3.2          Cause No. 50 "Requested facility not subscribed"

This cause indicates that the requested supplementary service could not be provided by the network because the user has no completed the necessary administrative arrangements with its supporting networks.

3.3          Cause No. 55 "Incoming calls barred within the CUG"

This cause indicates that although the called party is a member of the CUG for the incoming CUG call, incoming calls are not allowed within this CUG.

3.4          Cause No. 57 "bearer capability not authorized"

This cause indicates that the mobile station has requested a bearer capability which is implemented by the equipment which generated this cause but the mobile station is not authorized to use.

3.5          Cause No. 58 "bearer capability not presently available"

This cause indicates that the mobile station has requested a bearer capability which is implemented by the equipment which generated this cause but which is not available at this time.

3.6          Cause No. 63 "service or option not available, unspecified"

This cause is used to report a service or option not available event only when no other cause in the service or option not available class applies.

3.7          Cause No. 68 "ACM equal to or greater than ACMmax"

This cause is used by the mobile to indicate that call clearing is due to ACM being greater than or equal to ACMmax.

3.8          Cause No. 65 "bearer service not implemented"

This cause indicates that the equipment sending this cause does not support the bearer capability requested.

3.9          Cause No. 69 "Requested facility not implemented"

This cause indicates that the equipment sending this cause does not support the requested supplementary service.

3.10       Cause No. 70 "only restricted digital information bearer capability is available"

This cause indicates that one equipment has requested an unrestricted bearer service,
but that the equipment sending this cause only supports the restricted version of the requested bearer capability.

3.11       Cause No. 79 "service or option not implemented, unspecified"

This cause is used to report a service or option not implemented event only when no other cause in the service or option not implemented class applies.

4          Service or Option not implemented Class

4.1          Cause No. 81 "invalid transaction identifier value"

This cause indicates that the equipment sending this cause has received a message with a transaction identifier which is not currently in use on the MS-network interface.

4.2          Cause No. 87 "user not member of CUG"

This cause indicates that the called user for the incoming CUG call is not a member of the specified CUG.

4.3          Cause No. 88 "incompatible destination"

This cause indicates that the equipment sending this cause has received a request to establish a call which has low layer compatibility, high layer compatibility, or other compatibility attributes (e.g., data rate) which cannot be accommodated.

4.4          Cause No. 91 "invalid transit network selection"

For further study, treated as cause no. 95

4.5          Cause No. 95 "semantically incorrect message"

This cause is used to report receipt of a message with semantically incorrect contents.

5          Interworking Class

5.1          Cause No. 127 "interworking, unspecified“

This cause indicates that there has been interworking with a network which does not provide causes for actions it takes;
thus, the precise cause for a message which is being sent cannot be ascertained.

6          Protocol error (e.g., unknown message) class

6.1          Cause No. 96 "invalid mandatory information"

This cause indicates that the equipment sending this cause has received a message with a non-semantical mandatory IE error.

6.2          Cause No. 97 "message type non-existent or not implemented"

This cause indicates that the equipment sending this cause has received a message with a message type it does not recognize either because this is a message not defined, or defined but not implemented by the equipment sending this cause.

6.3          Cause No. 98 "message type not compatible with protocol state"

This cause indicates that the equipment sending this cause has received a message not compatible with the protocol state.

6.4          Cause No. 99 "information element non-existent or not implemented"

This cause indicates that the equipment sending this cause has received a message which includes information elements not recognized because the information element identifier is not defined or it is defined but not implemented by the equipment sending the cause. However, the information element is not required to be present in the message in order for the equipment sending the cause to process the message.

6.5          Cause No. 100 "conditional IE error"

This cause indicates that the equipment sending this cause has received a message with conditional IE errors.

6.6          Cause No. 101 "message not compatible with protocol state"

This cause indicates that a message has been received which is incompatible with the protocol state or that a STATUS message has been received indicating an incompatible call state.

6.7          Cause No. 102 "recovery on timer expiry"

This cause indicates that a procedure has been initiated by the expiry of a timer in association with 3GPP TS 24.008 error handling procedures.

6.8          Cause No. 111 "protocol error, unspecified"

This cause is used to report a protocol error event only when no other cause in the protocol error class applies.