VoLTE S1 handover completion (3/3)

After the UE confirms the completion of the S1 handover in a new cell, the target eNB initiates the completion procedure by sending towards the network. The completion procedure involves the SGW and PGW replacing the downlink S1 bearer from the source eNB to the source eNB releasing the UE associated resources and lastly, the release of Indirect Forwarding Tunnels by the SGW.

Figure 1. S1 handover procedure - complete

[12] The target eNB sends the Handover Notify to the MME notifying that the UE has been identified in the target cell and S1 handover has been completed.

• E-UTRAN CGI: globally identifies a cell and composed of PLMN identity and Cell identity.
• TAI: uniquely identify a Tracking Area and composed of PLMN identity and TAC (Tracking Area Code). 

Figure 2. Handover Notify

[13] The MME sends the Modify Bearer Request to the SGW requesting to switch the media path from the source eNB to the target eNB. The switch of media path from the SGW is done by updating the S1 bearer tunneling end point.

• Indication: includes various application flags. Refer to section 7.2.7 “Modify Bearer Request” in [TS 29.274].
• Bearer Context: identifies the bearer to be modified. It is composed of EPS Bearer ID and S1 eNB F-TEID sub elements.

In this practice, there are three bearers, i.e., bearer id = 5,6,7. The bearer 5 and 6 belongs to the internet APN, meanwhile the bearer 7 belongs to the IMS APN. The MME sends multiple Modify Bearer Request for each APN.

Note that in the following message, the value of F-TEID is set to 0x018088ed. This value is the one that was sent by the target eNB in step [4] Handover Request Acknowledge where it represents the tunneling end point of the target eNB for the downlink S1 bearer. Now, the MME deliver this value to the S-GW so the S-GW can use this value as a new target end point for the media path. As such, the downlink media path on S1 bearer is switched from the source eNB to the target eNB.

Figure 3. Modify Bearer Request for bearer 7

The following message shows the Modify Bearer Request for the bearer 5 and 6. In the same as described in the above, the value of F-TEID is set to 0x018008ed and 0x018048ed for bearer 5 and 6, respective. They are the same values as were sent by the target eNB in step [4] Handover Request Acknowledge where they represent tunneling end points of the target eNB for the downlink S1 bearer.

Figure 4. Modify Bearer Request for bearer 5 and 6

Note that the Modify Bearer Request is also sent by the SGW to the PGW which is not depicted here. The SGW and PGW are logically separated but in many cases, they are deployed on the same platform.

[14] The Modify Bearer Response sent from the PGW to the SGW and from the SGW to the MME.

• Cause: indicates the result of modifying the requested bearer.
• Bearer Context: identifies the bearer that has been modified. It is composed of EPS Bearer ID, Cause and S1 eNB F-TEID sub elements.

Note that in the following message, the value of F-TEID is set to 0x005b8422. This value is the one that was sent by the MME to the target eNB in step [3] Handover Request where it represents the tunneling end point of the SGW for the uplink S1 bearer. The tunneling end point values of SGW is created when the UE attaches the network at the very beginning. Upon S1 handover, the MME sends this value to the target eNB and the target eNB establishes uplink S1 bearer to the SGW using this value. At this moment, the source eNB also has uplink S1 bearer connection with the SGW with the same tunneling end points. As both source eNB and target eNB can send traffic to the SGW, there is no change that the data sent by the UE gets lost during handover procedure.

Now, the SGW sends this TEID to the MME for the downlink S1 bearer informing the tunneling end point for the downlink S1 bearer.

Figure 5. Modify Bearer Response for bearer 7

The same principal is applied to the following message which is for bearer 5 and 6.

Figure 6. Modify Bearer Response for bearer 5 and 6

[15] The MME requests the release of UE-associated S1 logical connections over S1 interface by sending UE Context Release Command. The source eNB releases its resources related to the given UE.

• UE S1AP ID Pair: contains the UE S1AP identifiers. It is composed of MME UE S1AP ID and eNB UE S1AP ID
• Cause: indicates the reason for this command. Refer to section 9.2.1.3 “Cause” in TS36.413 for the detail.

Figure 7. UE Context Release Command

[16] The source eNB confirms the release of UE-associated S1 logical connections over S1 interface by sending UE Context Release Complete.

• MME UE S1AP ID: uniquely identifies the UE association with the S1 interface within the MME.
• eNB UE S1AP ID: uniquely identifies the UE association with the S1 interface within the eNB.

Figure 8. UE Context Release Complete

[17] The MME requests the SGW to delete the Indirect Forwarding Tunnels by sending Delete Indirect Data Forwarding Tunnel Request.

Figure 9. Delete Indirect Data Forwarding Tunnel Request

[18] The SGW responds with Delete Indirect Data Forwarding Tunnel Response to the MME.

Figure 10. Delete Indirect Data Forwarding Tunnel Response

Red Mouse

REFERENCES

[1] 3GPP TS23.401, “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access”, v12.4.0, Mar 2014

[2] 3GPP TS29.274, “Evolved General Packet Radion Service (GPRS) Tunneling Protocol for Control Plane (GTPv2-C); Stage3”, v13.2.0, Jun 2015

[3] 3GPP TS36.411, "Evolved Universal Terrestrial Radio Access (E-UTRA); S1 Application Protocol (S1AP)", v13.0.0, Jun 2015

VoLTE S1 handover execution (2/3)

S1 handover preparation procedure includes the decision of S1 handover by the source eNB, allocation of network resources to establish Indirect Data Forwarding Tunnel among two eNBs and common S-GW and establishment of uplink S1 bearer from the target eNB to the S-GW. Once the S1 handover preparation procedure is completed, the MME initiates the S1 handover by sending Handover Command to the UE via the source eNB. The UE executes the handover by detaching from the source eNB and attaching to the target eNB. Meanwhile, the downlink data is forwarded to the target eNB and buffered while the UE handover is in progress. Lastly, the UE informs the target eNB of the fact that the handover has been successfully completed and thereafter, the buffered data and downlink data is forwarded the UE through the target eNB. 

Figure 1. S1 handover procedure - execution

[8] The Handover Command received from the MME is wrapped by the source eNB within the RRC Connection Reconfiguration and sent to the UE. The RRC Connection Reconfiguration is the message to perform logical, transport and physical channel configurations. In this case, it is used to send NAS signaling to the UE to reduce the latency. Upon receiving the Handover Command, the UE detaches from the source eNB and performs handover to the target eNB.

[9] The source eNB stops assigning PDCP-SNs to downlink packets and sends the eNB Status Transfer to the target eNB via MME that contains uplink and downlink PDCP-SN and HFN (Hyper Frame Number) for each respective E-RAB. This procedure is initiated by the source eNB at the moment when it considers the transmitter/receiver status to be frozen. The use of PDCP-SN and HFN is part of overflow control mechanism for radio. The PDCP-SN is the serial number of PDCP packets increasing up to MAX-PDCN-SN. If the number reaches the MAX-PDCP-SN, the HFN is incremented by one. 

• Subject to Transfer Items: contains uplink/downlink PDCP-SN and HFN for each respective E-RAB.
• E-RAB ID: Identifies a radio access bearer for a particular UE. This value remains the same after S1-handover.
• uL-/dL-Count value: contains the PDCP-SN and HFN values
• Received Status of UL PDCP SDUs: indicates the missing and the received uplink SDUs (Service Data Units) for each bearer for which the source eNB has accepted the request from the target eNB for uplink forwarding.

  

Figure 2. eNB Status Transfer

[10] The MME forwards the received PDCP-SN and HFN information to the target eNB by sending MME Status Transfer. Upon receiving the MME Status Transfer, the target eNB does not deliver any uplink packet whose PDCP-SN is lower than the value received in the PDCP-SN in the uL-COUNT value. The target eNB uses the received PDCP-SN in the dL-COUNT value for the first downlink packet for which no PDCP-SN is assigned yet. The downlink traffic received by the source eNB is routed to the target eNB following the Indirect Data Forwarding Tunnel.

[11] After the UE successfully synchronized with the target cell, it sends a Handover Confirm to the target eNB. The Handover Confirm is contained in the RRC Connection Reconfiguration Complete message on RRC. Please note that, at this moment, there is no direct S1 bearer established yet between S-GW and the target eNB. Therefore, the downlink data is sent to the source eNB and forwarded to the target eNB following the Indirect Data Forwarding Tunnel. The uplink data from the UE will be forwarded to the S-GW following the direct S1 interface.

Red Mouse

REFERENCES

[1] 3GPP TS25.331, "Radio Resource Network (RRC); Protocol specification", v12.3.0, Sep 2014

[2] 3GPP TS23.401, “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access”, v12.4.0, Mar 2014

[3] 3GPP TS36.331, "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification", v12.3.0, Sep 2009

[4] Blog, “How LTE Stuff Works?: RRC Connection Reconfiguration”, Oct 2011

VoLTE S1 Handover preparation (1/3)

While UE crosses the border towards the neighborhood cell, the source eNB determines whether there needs a handover based on the received measurement report from the UE. When there is no established X2 connection with the target eNB, the source eNB determines to perform S1 handover. In this post, the handover preparation phase will be addressed. The handover preparation procedure includes the determination of handover by the eNB, handover request by the MME, the allocation of required resources and establishing the indirect data forwarding tunnels among NEs.

I. Indirect Data Forwarding Tunnel

S1 handover is different from the X2 handover in that the media is anchored by the SGW under the control of MME rather than by eNB. During the S1 handover, a temporary indirect data forwarding tunnel is established between two eNBs via the common SGW. All the media arriving at the source eNB while S1 handover is in progress, which can be uplink data from UE side or the downlink data from the network side, will be re-directed to the target eNB through this indirect data forwarding tunnel and buffered at the target eNB. When the S1 handover is completed, the buffered media at the target eNB is transferred to the UE. The following diagram shows Indirect Data Forwarding Tunnel established between the source eNB and target eNB anchored by the common SGW during S1 handover procedure.

Figure 1. Indirect Data Forwarding Tunnel in S1 handover

II. S1 handover preparation

As a precondition of this practice, the UE has PDN connections with the internet APN and IMS APN and there are three EPS bearers established in total with EPS bearer ID of ‘5’, ‘6’ and ‘7’ and the relocation of SGW/PGW does not occur. The S1 handover procedure is triggered by the source eNB. The MME controls establishing the Indirect Data Forwarding Tunnel by intermediating required data between two eNBs like Bearer Context. The Bearer Context contains EPS bearer ID and their GTP-U TEIDs corresponding to each EPS bearers. The SGW anchors the media transfer between source eNB and the target eNB. As the SGW and two eNBs are involved in the media control, they allocate the required media resources, generate their own GTP-U TEIDs and establishes S1 bearer and indirect data forwarding tunnels based on the GTP-U TEID of the peer node delivered via MME.

Figure 2. S1 handover procedure - preparation

[1] The UE periodically sends a measurement report to the serving eNB. This reporting mechanism is intended for the UE to find out the best cell to communicate with the network. The measurement report may contain the list of neighbor cells, signal strength, current condition, etc.

[2] Based on the received report, the serving eNB determines whether the handover is required and if it is required, the serving eNB selects a target eNB among the list of neighbor eNBs. If there is no X2 connection with the target eNB, the source eNB performs S1 handover and sends Handover Required to the serving MME requesting to prepare for resources at the target. 

•  MME UE S1AP ID: Unique identifier of the UE association over the S1 within the MME
• eNB UE S1AP ID: Unique identifier of the UE association over the S1 within the eNB
• Handover Type: The type of triggered handover in the source side (i.e., intraLTE, LTEtoUTRAN, LTEtoGERAN, UTRANtoLTE, GERANtoLTE)
• Cause: A reason for a particular event for the S1AP. In this practice, the value “Handover Desirable for Radio Reasons” indicates that the cause is related with radio. Refer to section 9.2.1.3 Cause of [TS36.413] for the detail.
• Target ID: The target eNB for the handover. It is composed of “Global eNB ID” and “selected TAI”. The Global eNB ID is composed of PLMN ID (MCC+MNC) and macro eNB-ID identifying the specific eNB of a certain operator in a certain country. The selected TAI uniquely identifies the target Tracking Area i.e., PLMN ID + TAC, identifying a specific tracking area that is served by that eNB.
• Source to Target Transparent Container: Information elements created by the source eNB and transmitted to the target eNB, which contains the RRC related information, E-RAB information, Target Cell-ID and UE History Information as shown in the following bullets.
• RRC Container: RRC Information used by the target eNB during handover preparation including UE capability information. Refer to “HandoverPreparationInformation” in section 10.2.2 “Message definitions” of TS36.331 for the detail.
• e-RABInformationList: The list of eRAB to be handed over. The E-RAB ID identifies a radio access bearer for a particular UE, which makes the E-RAB ID unique over one S1 connection. The “dL-Forwarding-proposed” indicates that the source eNB proposes the list of E-RABs for forwarding of data. In this practice, there are three E-RABs (i.e., E-RAB ID=’5’,’6’ and ‘7’) proposed and they actually represent existing E-RABs of the source eNB. If the target eNB accepts it in the Handover Request Acknowledge, the downlink data received by the source eNB during the handover will be forwarded to the target eNB through the indirect data forwarding tunnel.
• Target Cell ID: Globally unique cell identifier. It is composed of PLMN ID and Cell ID.
• UE-HistoryInformation: The list of cells that a UE has been served by in the active state prior to the target cell.

Figure 3. Handover Required

[3] the MME initiates the procedure by sending the Handover Request to the target eNB requesting to prepare for resources for handover.

•  MME UE S1AP ID: refer to step#2.
• Handover Type: refer to step#2.
• Cause: refer to step#2.
• UE-AMBR: Aggregated maximum bit rates per UE being applicable for Non-GBR bearers.
• E-RAB to be SetupList: A list of E-RAB to be setup where each item contains E-RAB ID, Transport Layer Address, GTP-TEID and E-RAB level QoS parameters as addressed in the following bullets.
• E-RAB ID: Refer to step#2
• The Transport Layer Address : IP address of the source eNB.
• The GTP-TEID : The GTP Tunnel Endpoint Identifier of the SGW towards the source eNB. This has been known to the MME during the initial attach of the UE and used by the source eNB to maintain the S1 bearer with the SGW. Now, the MME intends to take this to the target eNB to replace the existing S1 bearer in the end.
• E-RAB Level QoS Parameters indicates the QoS to be applied to the corresponding E-RAB. It is composed of QCI and ARP. Refer to the section 9.2.1.60 “Allocation of Retention Priority” in TS36.413 for the detail.
• Source to Target Transparent Container: Information elements created by the source eNB and transmitted to the target eNB. Refer to step#2.
• UESecurityCapabilities: Supported algorithms for encryption and integrity protection in the UE.
• HandoverRestrictionList: Roaming or access restrictions for subsequent mobility action for which the eNB provides information about the target of the mobility action towards the UE.
• SecurityContext: Security related parameters to the eNB which are used to derive security keys for user plane traffic and RRC signaling messages and to generate security parameters for the current S1 handover. 

Figure 4. Handover Request

[4] The target eNB allocates all the necessary resources for the admitted E-RABs and establishes uplink S1 bearer with the SGW. The target eNB creates its own GTP TEID for S1 bearers which will be delivered to the SGW later and used by the SGW to establish the downlink S1 bearer (SGWàtarget eNB), thereby replaces that the source eNB. The uplink and downlink GTP-TEID for each admitted E-RABs are also included. These DL/UL GTP-TEIDs are used for indirect media transfer. The target eNB responds with the Handover Request Acknowledge to the MME.

• MME UE S1AP ID: refer to step#2.
• eNB UE S1AP ID: refer to step#2.
• E-RAB Admitted List: The list of E-RAB for which the target eNB admitted to establish. This is composed of E-RAB ID, GTP-TEID, UL/DL GTP-TEIDs and the Transport Layer for each Admitted Item as addressed in the following bullets.
• E-RAB ID : Refer to step#2.
• GTP-TEID indicates GTP Tunneling Endpoint Identifier of the target eNB which will replace the corresponding GTP-TEID of the source eNB in the end (i.e., downlink S1 bearer).
• The DL/UL GTP-TEIDs indicate the Tunneling Endpoint Identifiers of the target eNB for Indirect Data Forwarding Tunnels. The following diagram shows the GTP TEID for indirect data forwarding dedicated for one E-RAB.
•  Target to Source Transparent Container: Information element that is used to transparently pass radio related information from the handover target to the handover source through the MME. The Handover Command is transparently delivered to the source eNB.

  

Figure 5. Handover Request Acknowledge

[5] Upon receiving the Handover Request Acknowledge, the MME sends the Create Indirect Data Forwarding Tunnel Request to the SGW, which contains the Bearer Context for each bearer which was received at step #4 from the target eNB. The Bearer Context represents the attributes of each bearer including bearer identifier and TEIDs as below:

• EPS Bearer ID : Identifier of EPS bearer to be established.
• eNB F-TEID for DL data forwarding: GTP Tunneling Endpoint Identifier created by the target eNB for downlink data forwarding. Refer to step#4 
• eNB F-TEID for UL data forwarding: GTP Tunneling Endpoint Identifier created by the target eNB for uplink data forwarding. Refer to step#4 

  

Figure 6. Create Indirect Data Forwarding Tunnel Request

[6] Upon receiving the Create Indirect Data Forwarding Tunnel Request, the SGW establishes the Indirect Data Forwarding Tunnel towards the target eNB using the received DL/UL eNB F-TEIDs. The SGW allocates its own UL/DL F-TEID for indirect data forwarding tunnel, which is delivered to the source eNB via MME at step #7. The SGW responds to the MME with the Create Indirect Data Forwarding Tunnel Response which contains the Bearer Context of the SGW.

• Cause : Indicates if the Indirect Data Forwarding Tunnel has been created in the SGW. Refer to section 7.2.19 “Create Indirect Data Forwarding Tunnel Response” of TS29.274 for the detail.
• EPS Bearer ID : refer to step #5.
• SGW F-TEID for DL data forwarding: GTP Tunneling Endpoint Identifier created by the SGW for downlink data forwarding.
• SGW F-TEID for UL data forwarding: GTP Tunneling Endpoint Identifier created by the SGW for uplink data forwarding.

  

Figure 7. Create Indirect Data Forwarding Tunnel Response

[7] The MME sends the Handover Command to the source eNB informing that resources for handover has been prepared at the target eNB. Upon receiving the Handover Command, the source eNB establishes Indirect Data Forwarding Tunnel towards the SGW using the received E-RAB Subject to Data Forwarding List, i.e., DL/UL GTP-TEIDs for each E-RAB.

• MME UE S1AP ID: refer to step#2.
• eNB UE S1AP ID: refer to step#2.
• Handover Type: refer to step#2.
• E-RAB Subject to Data Forwarding List : The list of E-RAB items to be used for indirect data forwarding. Each E-RAB Data Forwarding Item identifies the E-RAB context of each E-RAB and it consists of E-RAB ID, DL/UL GTP-TEIDs as addressed below.
• E-RAB ID: Refer to step #2.
• DL/UL GTP-TEIDs : Tunneling End Point Identifier of the SGW created and delivered at step #6 for the Indirect Data Forwarding Tunnel.
• Target To Source Transparent Container: Radio related information transparently delivered to the source eNB through the MME. It was created by the target eNB and sent to the MME at step #4.

Figure 8. Handover Command

Red Mouse

REFERENCES

[1] 3GPP TS25.331, "Radio Resource Network (RRC); Protocol specification", v12.3.0, Sep 2014

[2] 3GPP TS24.301, "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage3", v12.4.0, Mar 2014

[3] 3GPP TS24.008, "Mobile radio interface Layer 3 specification; Core network protocols; Stage3", v13.4.0, Dec 2015

[4] 3GPP TS29.274, "3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS); Tunneling Protocol for Control Plane (GTPv2-C); Stage3", v13.0.0, Dec 2014

[5] 3GPP TS36.331, "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification", v12.3.0, Sep 2009

[6] 3GPP TS36.413, "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP)", v12.3.0, Sep 2014

Google Connecting the dots with RCS

As was expected among many players in Rich Communication industry, Google announced at MWC 2016 that they will provide ways for operators to accelerate the spread of RCS service across the globe. Two main hazards, i.e., complicated RCS technologies and interoperability, will be taken care of by Google. The cloud based RCS platform and RCS hub platform are available to operators for quick-and-easy launch of their RCS service.

Universal RCS profile

Google will define the Universal RCS profile which addresses basic features of RCS service including:

§   One to one chat

§   Group Chat

§   IMDN (delivered, displayed)

§   Contents Sharing (audio, video, photo)

In order to make this happen, Dozens of Global operators are partnered with Google in working for RCS:

§   America Movil (Mexico)

§   Bharti Airtel Ltd (India)

§   Deutsche Telekom (Dutch)

§   Etisalat (UAE)

§   Globe Telecom (the Philippines)

§   KPN (Dutch)

§   Millicom (Africa, Hispanic America*)

§   MTN (Africa)

§   Orange (merged with T-Mobile UK as a joint venture, EE)

§   PLAY (Poland)

§   Smart Communications (the Philippines)

§   Telenor Group (Norway)

§   TeliaSonera (Sweden, Finland)

§   Telstra (Australia)

§   TIM (Italy)

§   Turkcell (Turkey)

§   VimpelCom (Russia)

§   Vodafone (UK), Sprint (USA)

OTT vs Pre-Installation vs Embedded

Once the Universal RCS profile is specified with the help of global operators, it is expected that Google will introduce the OTT RCS client for Android OS. As opposed to the expectation that RCS client will be embedded in Android OS as a competitor to iMessage, the decision on whether it is pre-installed or embedded seems to be left to operators at least in the short term. In addition to the RCS client, Google will also provide the developers APIs which enables operators to flexibly customize their RCS clients with operator specific features on top of Universal RCS profile.

In the meantime, Google will keep doing their business with cloud based RCS service. It is a quick-and-easy way for operators to launch their RCS service. Even though using Google’s cloud-based RCS platform would be cost-efficient way, operators may worry that they can end up with being too leaning on Google.

Considerations

According to Mr. Stephen Sale, Research Director of Analysis Mason, Operators need to take the following strategical considerations:

§   How to distribute the RCS service worldwide: Even with Google’s help for Android OS, there still remains the worry that Apple won’t provide the RCS in iOS. Google may be able to put OTT RCS client with Universal RCS profile in the AppStore but even in this case, operators may not be able to provide operator specific RCS client for iOS.

§   Brand proposition: Some operators who already have their own RCS services with different brand name e.g., Sprint’s Messaging Plus, T-Mobile’s Advanced Messaging will need to figure out how to position its already existing RCS service against the soon-to-be-coming Google’s RCS client. Other operators who does not have RCS service yet will have to figure out how they can differentiate their RCS service against competitors.

§   Strategy Beyond messaging client: After the RCS service with Universal profile is stabilized, operators need to consider how they can monetize the service. As there are already lots of prevailing OTT competitions out there, operators have to figure out the feasible differentiator to get traction from users.

In order to gain traction of users, RCS service should be the ‘out-of-box’ service. It was already empirically proven that OTT RCS client can not compete with the existing OTT messaging services. Users needs be able to use the RCS service in the same way as SMS/MMS without even noticing they are using RCS. Without leveraging user experiences already familiar to users, operator’s RCS service won’t be able to regain the market. Having said that, operators need to provide pre-installed or embedded RCS clients.

Google Connecting the dots using RCS

Google does already have user's web context. They can indirectly figure out user’s profile like gender, age, interests, location, etc. by tracking down user’s behaviors on the web. By incorporating operators into their cloud based RCS service, Google can track down communication context of users as they do for web services. User’s communication context may include user’s communication behavior like how often they communicate, where they communicate, when they communicate, how long they communicate at a time and with whom they communicate. User’s communication history is important meaning to Google as it is closely related with user’s social relationships. Once user’s relationship can be figured out and if Google can connect the dots between web context and communication context of the same user, Google will be able to compete with the prevailing Social Network Services like Facebook.

In addition to this, operators may need to open the door of its subscribers database to Google for user authentication and authorization. Once subscriber’s database stored in the operator’s network is open to Google, they will be able to come to obtain the details of subscribers profile (of course) to an extent that is allowed by operators. Even though Google provides its own cloud-based RCS platform for free to operators, if they can obtain user's full context across web and mobile, it would be a trade much marginal to Google.

Figure 1. Google connecting the dots

References

[1] Fiercewireless, “As RCS struggles, T-Moble shows progress with 5.5M Advanced Messaging users and 40M messages/day”, by Collin Gibbs , 29^th Feb 2016

[2] Communications Developer Zone, “Google Partners with Mobile Operators for RCS Rollout”, by Michelle Amodio, 29^th Feb 2016

[3] iNews Journal, “Google is Working on RCS the New Competitor of Whatsapp and iMessage”

[4] ST GIST, “Google’s Android Dives Into Text Message Upgrade (RCS) Initiative”, by Jason Raphael Labuguen, 24^th Feb 2016.

[5] PC, “Google, Global Carriers Team up to Improve Text Messaging”, by Stephanie Mlot, 23^rd Feb 2016

[6] KNOWLEDGE CENTER, “Google makes RCS viable for many operators, but operators will need to think beyond the messenger client”, by Stephen Sale, 29^th Feb 2016

[7] Makeuseof, “Google Jibe is Here: Say Goodbye to SMS & MMS Messages”, by Matthew Hughes, 1^st Mar 2016

[8] CLOUD FENDER, “6 Links that will show you what Google knows about you”