. MOTOROLA and the Stylized M Logo are registered in the US Patent & Trademark Office. All other product or service names are the property of their respective owners. © Motorola, Inc Supports: C02A__MOT_RIM_macro_RF_loss.pdf Title: Source:Motorola – Ron Crocker, John Harris Date:31 October 2006 AN Macros – Overview Notice ©2006 Motorola, Inc. Motorola Incorporated grants a free, irrevocable license to 3GPP2 and its Organization Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner’s name any Organizational Partner’s standards publication even though it may include portions of the contribution; and at the Organization Partner’s sole discretion to permit others to reproduce in whole or in part such contributions or the resulting Organizational Partner’s standards publication. Motorola Incorporated is also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner’s standard which incorporates this contribution. This document has been prepared by Motorola Incorporated to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on Motorola Incorporated. Motorola Incorporated specifically reserves the right to amend or modify the material contained herein and nothing herein shall be construed as conferring or offering licenses or rights with respect to any intellectual property of Motorola Incorporated other than provided in the copyright statement above.

2 During any call, when RF loss of one party occurs, it wastes users time & leads to misunderstandings Avoiding this problem requires AT to frequently send resource consuming keep alive messaging to server (as media AND/OR control) –This results in increased user sensitivity to RF loss -- limiting capacity RF loss also wastes RF resources at user which did not drop –this user stays on channel longer, sending media packets that are unnecessary/will not be listened to. Proposed solution: AT sends new message to AN consisting of a single packet and single trigger, instructing the AN to send the packet (e.g., SIP message) when the trigger is encountered at the AN (e.g., RF loss on connection with AT). –AT uses air interface message to provide AN with simple instruction to be performed on the AT’s behalf. –Solution does not involve AN actually becoming aware of any application functionality - it doesn’t look inside the packet, it just relays it –Instead, the AT uses its inherent application knowledge to create a simple instruction for the AN to execute on its behalf –This instruction is what is referred to in this contribution as an “AN Macro”. Background – AN Macros

3 Use case 1: Telephony call Background: –User is participating in a telephone call. Normal conversation mode. User experiences RF loss Without AN Macro: –When User experiences RF Loss: AN/PCF determines that User has experienced RF Loss and releases the connection resources for this user. Concurrently, media packets stop coming from User to the Core due to RF Loss condition. The Core eventually (10 seconds?) determines that no media packets are coming from User and terminates the call OR other party guesses that the other party has been lost (asks User a question and gets no response) and terminates the call. With AN Macro: –At (or before) beginning of call AT application creates AN Macro for RF Loss event to inform Core of RF Loss condition. –When User experiences RF Loss: AN/PCF determines that User has experienced a RF Loss (<500ms) and both releases the connection resources for this user and sends packet(s) associated with RF Loss trigger. Core is notified by the(se) AN Macro packet(s) that User is experiencing RF difficulties and takes appropriate application-level action (inform other party, terminate call, …).

4 Use case 2: Conference call Background: –Much like UC1, but user is listening-only (e.g., conference call participant, but muted) - uplink packets only for keep-alive purposes. –In this case, because User is quiet, silence suppression would not generate any user traffic, but periodic heartbeat kinds of traffic is sent to keep the keep-alive mechanism happy Without AN Macro: –When User experiences RF Loss: AN/PCF determines that User has experienced RF Loss and releases the connection resources for this user. Concurrently, media packets stop coming from User to the Core due to RF Loss condition. The Core eventually (10 seconds?) determines that no media packets are coming from User and terminates the call OR other party guesses that the other party has been lost (asks User a question and gets no response) and terminates the call. With AN Macro: –At (or before) beginning of call AT application creates AN Macro for RF Loss event to inform Core of RF Loss condition. –When User experiences RF Loss: AN/PCF determines that User has experienced a RF Loss (<500ms) and both releases the connection resources for this user and sends packet(s) associated with RF Loss trigger. Core is notified by the(se) AN Macro packet(s) that User is experiencing RF difficulties and takes appropriate application-level action (inform other party, terminate call, …).

5 Use case 3: Push-to-talk call Background: –User is involved in a PTT call (1to1 or 1toMany) and is listening OR speaking OR the floor is open (neither listening nor speaking). –When the User is quiet (i.e., floor open or listening), no user traffic is generated. Periodic heartbeat kind of traffic is sent to keep the keep-alive mechanism happy. Without AN Macro: –When User experiences RF Loss: AN/PCF determines that User has experienced RF Loss and releases the connection resources for this user. Concurrently (when speaking):  Media packets will stop coming from the User to the Core. The Core eventually (10 seconds?) determines that no media packets are coming from User and terminate the call (1to1) or open the floor (1toMany) Concurrently (when floor open or listening):  heartbeat packets stop coming from User to the Core. The Core eventually (10 seconds?) determines that no media packets are coming from User and terminates the call (1to1) or removes this user from the call (1toMany). With AN Macro: –At (or before) beginning of call AT application creates AN Macro for RF Loss event to inform Core of RF Loss condition. –When User experiences RF Loss: AN/PCF determines that User has experienced a RF Loss (<500ms) and sends packet(s) associated with RF Loss trigger. Core takes the appropriate action based on the state of the call (e.g., the floor is opened or the call is terminated, as appropriate).

6 How might this work? The application in the AT sends an APPLICATION PACKET (IP packet, opaque to the AN), along with a TRIGGER CONDITION (e.g., RF Loss) to the AN via a new L2/3 message - let’s call this message “EstablishMacro” –The AT can cancel the macro at any time via another L2/3 message - let’s call this one “CancelMacro” The AN stores the macro (both trigger condition and application packet) until the trigger condition occurs When the trigger condition occurs, the AN delivers the application packet to the rest of the system much as if it had just arrived as a new packet.

7 An example… A calls B, B answers, B has RF Loss ARANASERVERRANBB [1] INVITE [CSeq: INVITE] First request, also happens to create a dialog. [a.2] 100 Trying [CSeq: INVITE] 100 Trying is not a "request," it's a "response" [b.3] INVITE [CSeq: INVITE] Ring! [b.4] 180 Ringing [CSeq: INVITE] [b.5] 180 Ringing [CSeq: INVITE] Hello? [6] 200 OK [CSeq: INVITE] [a.7] ACK [CSeq: INVITE] [b.8] 200 OK [CSeq: INVITE] [a.9] CachePacket(BYE [CSeq: BYE]) My local sequence number is null, so I can pick anything I want. [b.10] CachePacket(BYE [CSeq: BYE]) A's local sequence number is set to 12345, so the BYE MUST use [b.11] ACK [CSeq: INVITE] [12] Thrilling conversation... [13] RF Loss [14] BYE [CSeq: BYE] [15] BYE [CSeq: BYE] Continue the normal SIP procedure - no other changes

8 Question areas for TSG-X/-S Utility –Does this capability provide utility in 3GPP2 Phase 2 Evolution? Security –Does this capability create any new security issues?

9 Some constraints on application packets Due to the store-and-forward nature of the mechanism, the application packet should not contain time-sensitive information –This includes both information within the packet as well as information about the packet (e.g., its encryption status). While there is no explicit notion of ordering, multiple AN macros may exist for a given AT, all of which depend on the same trigger condition, and the corresponding application packets will be delivered in some order –One order is order of arrival at the AN, much like the native data service; other orders can be created if necessary. To minimize storage requirements within the AN, the cumulative size of all macros outstanding for a given AT may be limited –This is more of an implementation requirement than a conceptual one, but it may have impact on certain applications ability to use this capability

10 Utility - Is this feature useful given the constraints? Consider use with SIP - Can we pre-establish an AN Macro comprising a BYE message with a RF Loss trigger condition? –The constraints applicable here is w.r.t. time-sensitive information There are no specific requirements in RFC3261 that a request message (e.g., BYE ) contain any timestamp or any other time- sensitive information, but… There ARE specific requirements in RFC3261 regarding sequence numbers (contained in the CSeq: header) within these messages that are not time sensitive, but are context sensitive

11 Security - are any new problems created? No new problems are created using this method: –The AN already sees every packet sent between the AT and the network –The AN does not need to inspect the macro packet content to do its job –The AN does not create the packet content - the AT creates the content and stores it in the AN