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

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

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. 

GSM/UMTS/LTE: Supplementary Service