1. 1 1 Title: The Impacts Analysis of M2M Functions in 1xRev F on Network Sides Abstract: This contribution analyzes the impacts to TSG-A and TSG-X when supporting 1x Rev F M2M functions in network sides. Recommendation: For discussion Source: Contact : Yu.yuanfang@zte.com.cnYu.yuanfang@zte.com.cn; Zhao.xiaowu@zte.com.cn ;Zhao.xiaowu@zte.com.cn Lu.ting@zte.com.cnLu.ting@zte.com.cn; yfang@zteusa.comyfang@zteusa.com

2. 2 Overview TSG-C has developed 1x Rev F (C.S0001~5-F v1.0) to support M2M services over 1x network, which entered into V&V phase TSG-A has decided A.S0025-0 as M2M IOS Spec for supporting for M2M over cdma2000 networks, including both 1x and HRPD networks A contribution, A30-20120806-006r1 ZTE IOS enhancement for 1x RevF (M2M).doc, initiated the discussion in TSG-A It was found the core network may be impacted when supporting for M2M features defined in 1x Rev F More information can refer to the revised contribution A30- 20121015-011Ar0 ZTE IOS enhancement for 1x RevF (M2M).doc

3. 3 M2M features in 1x Rev F need IOS support The features defined in 1x Rev F achieve two goals: –longer battery life –larger network capacity The features need IOS support are: –Smaller paging areas for fixed M2M Device –Bypass air interface service negotiation by pre-provisioned parameters to reduce call setup time –Longer registration timer to reduce the times of timer-based registration –Bigger slot cycle index to reduce the wake up times of M2M device –Direct channel assignment without paging to reduce call setup time and network signaling load M2M Device Capability Information is introduced and delivered between BS and MSC to support the above features

4. 4 M2M Device Capability Information M2M Device Capability information includes: –Non-Mobility indictor: To indicate whether the M2M Device is fixed in some specific areas. The MSC may use it to page the M2M Device in these specific areas. –Default SO33 Parameters indicator: To indicate whether the M2M Device supports to use the pre-provisioned negotiation parameters for SO33. The service negotiation in air interface can be bypassed based on it, then a short call setup time may be achieved. –Extended Slot Cycle Index(SCI) indicator: To indicate whether the M2M Device supports to extend the SCI to a bigger value, then the device may get a longer battery life with reduction times of waken up

5. 5 M2M Device Capability Information(cont.) –Extended Registration Timer indicator: To indicate whether the M2M Device supports to extend the registration timer to a bigger value. The MSC may set a longer deactivated detection timer for the M2M Device based on it, then the device may get a longer battery life with reduction times of time-based registration –Direct Channel Assignment (DCA) Supported indicator: To indicate whether the M2M Device supports DCA without receiving paging. A short call setup time may be achieved.

6. 6 1x Rev FImpacted A1/A1p Smaller paging areas for fixed mobile (mobility indicator) Introduce M2M Device Capability Information to following messages: Location Updating Request, CM Service Request, Paging Response, Assignment Request, Paging Request Call setup without service negotiation (default SO33 parameters indicator) Same as above Extended SCI (Extended SCI indicator) Same as above MT call with direct channel assignment (DCA supported indicator) Same as above Extended registration timer (Extended REG timer indicator) Introduce M2M Device Capability Information to Location Updating Request, CM Service Request, Paging Response messages Impacts to A Interface

7. 7 Example Call Flow: M2M Device Initiated Location Registrati on

8. 8 Example Call Flow:M2M Device Initiated PDSI Setup - Packet Data Session is Dormant or Inactive

9. 9 Example Call Flow : Network Initiated PDSI Reactivation when the Packet Data Session is Dormant

10. 10 Example Call Flow : Network Initiated PDSI Reactivation via DCA

11. 11 Possible impacts to TSG-X Storage of M2M Device Capability information during M2M Device registration –Where to store Device capability information? MSC,HLR? –Do we need to change existing MAP protocol or just adds some description in A.S0025 to avoid MAP modifications? Any other impacts?