20060829 VSWG Conference Call Minutes

From CDGWiki

Jump to: navigation, search

Call Date/Time: Tuesday 29 August, 2300 UTC (1600 PDT)

Contents

[edit] Agenda

  1. SMS Billing Proposal
  2. SMS Signaling: Maximum Message Length

[edit] Participants

Representatives of the following companies attended the call:

  • CDG
  • KDDI
  • QUALCOMM
  • Sprint-Nextel
  • Telecom New Zealand
  • VeriSign
  • Vivo

[edit] Discussion

[edit] SMS Billing Proposal

  • We briefly reviewed v0.3 of the SMS Signaling for Roaming Billing Click_to_view_or_edit_the_discussion_page.gifdocument. This proposal is updated to capture the decision from the June IRT, which saw operators prefer a transport-layer means of identifying the serving network in SMS signaling, so that this can be captured in the MC/SMSC billing record. A transport-layer approach should require few if any changes to existing MCs.
  • Point Code Proliferation:
    • Confirmed that the current proposal requires the RSP to appear as a large number of point codes: A complete set of serving operator PCs for each home operator/country.
    • VeriSign: Can't we use a consistent value for a particular serving operator towards every home operator? The actual value used in the MC billing record is not important, so long as it is different for each serving operator. If it's not used for routing, it could be anything. QUALCOMM (Daniel): Agree that this would be good, but I don't see how it can be done.
    • Action: VeriSign and QUALCOMM to discuss offline to see if the proposal can be simplified.
  • Multiple RSP Scenarios:
    • These are not addressed in the current document. E.g. if a subscriber from a network customer of RSP1 roams to a network that is a customer of RSP2, can this proposal work?
    • Answer: Inter-RSP communication should at a high level be no different from RSP-Operator communication: the signaling needs to uniquely identify the true serving network. But this should be spelled out in the document.
    • Action: QUALCOMM to update the document to include multi-RSP.
  • Solution Options:
    • Two flavors of the solution are required, to suit operators who use PC routing, and those who use Global Title.
      • An operator will only see one flavor - the requirement is instead an impact on the RSPs who have to support both.
    • Within the PC routing flavor, there are two options for where to carry the serve-specific PC: in MTP, or in SCCP.
      • There should be little difference between the two options as far as operators are concerned - SCCP may be an easier route for the RSPs.
  • Operator Readiness:
    • Do operators need this now? If it were available today, could they make use of it?
    • TNZ: The lack of differentiated billing is affecting us today, and forcing inaccurate pricing. The billing system has recently been modified to be ready for this solution - it should be a very small change to support and rate on multiple PCs in the billing record.
    • For other operators, the necessary billing system changes may be more complex, but this work could be scheduled/prioritized more easily if there were a known date for when the solution would be available from the RSPs. A number of operators have indicated that SMS roaming billing is a high-priority issue for them.
  • RSP Readiness
    • VeriSign noted that the proposed solution could be built using their existing capabilities

[edit] SMS Signaling: Maximum Message Length

  • We reviewed the "Message Length" section of v0.5 of the draft CDG Reference Doc 133 Click_to_view_or_edit_the_discussion_page.gif(aka SMS Roaming White Paper). The general scenario we are considering is when a message delivery (either MO or MT) is attempted that is longer than the current network can handle. Different maximum values in different networks may mean that this issue is particularly noticeable when roaming, e.g. a message that can normally be sent/received at home fails while roaming.
  • Length Variations:
    • The document contains a link to a 2003 IRT survey result that shows the different length limits for some CDMA operators.
    • If all operators used the same maximum length, we would have fewer issues. However this seems unlikely: all operators would have to agree on the lowest maximum supported by any other operator, effectively limiting their network and subscribers because of someone else's implementation. Even assuming MCs can apply a limit, existing deployed MSs may have their own settings that exceed this "lowest maximum".
    • Understanding the true limit, and exactly which layer of the protocol imposes it, can be tricky. The hard limits for SMS on the air and ANSI-41 interfaces are set low down in the protocol stack, where they can be affected by variable-length overhead not directly part of the user's message. Handsets, Message Centers and external SMEs may impose application-layer limits in a somewhat arbitrary fashion. Use of dedicated vs common signaling channels (i.e Traffic Channel vs Access/Paging Channel) can have a big impact on the maximum message length for the air interface.
  • Failure Notifications:
    • If we accept that different networks may have different limits, then from time to time we will have a message attempted that cannot be delivered. It becomes important to notify the message sender (perhaps the MC (for MT-SMS) or even the original sender) that the message could not be delivered. Even if the message is truncated to allow partial delivery, some indication to the sender is helpful.
    • In some MT cases, we see "message jamming", where the overlength message remains at the head of the message queue, and is always retried before any other delivery attempts. This can stop all SMSs for the affected subscriber for several days! Explicit notification back to the MC should enable the MC to take some intelligent action and avoid the jamming phenomenon.
    • The ANSI-41 SMS_CauseCode "User Data size error" appears to be the best way to advise of an overlength problem. Operators and RSPs are encouraged to use this response wherever applicable.
      • This cause code can also be sent in an SMS Acknowledge Message in response to a MO message that successfully reaches the MSC, but is too long for the SS7 interface to the MC.
      • In some cases the receiving entity may not be able to send the appropriate cause code (e.g. not implemented, or segmentation not supported). In this case the RSP may have a key role to play: If the message exceeds a preconfigured maximum for the destination network, the RSP can send the cause code back on behalf of the destination.
    • The actions taken on receipt of an overlength notification (e.g. segment (see below), truncate, discard, send notification to original sender) are in general up to the receiving entity.
    • The use of a Welcome SMS to advise the roamer of their serving network maximum SMS length was discussed. This could preemptively avoid overlength message attempts. The Welcome SMS is already used by some operators to advise addressing differences for SMS as compared to voice - advice of another limitation may be perceived negatively. The advice would not help for MT messages, where the original sender may be unaware that the destination party is roaming.
  • Segmentation and Reassembly (SAR):
    • A common way to deal with long messages is to divide them into multiple smaller parts.
    • Several operators today use SCCP SAR. Unfortunately this is not supported by all their roaming partners, and may not be supported by all RSPs.
      • As an interim recommendation, operators who use SCCP SAR at home should not send segmented messages to roaming partners. This can be achieved either via static configuration data in the MC, or via implementation of the ANSI-41-E reporting mechanism for SAR support.
      • When the RSP supports SAR but the serving network does not, the RSP can send an overlength cause code as discussed above.
      • The subsequent handling by the MC is not specified, but see the list above.
    • An alternative segmentation method uses WEMT to encapsulate segmented GSM SMSs inside ANSI-41/IS-637 messages.
      • This approach has the advantage of not requiring any special capabilities in the RSP or serving network, although handset support is needed.
      • At least some handsets/networks support WEMT, but the extent of support is unknown.
      • Operators interested in sending long SMSs are recommended to investigate their possibility to use WEMT.
      • The message will appear as multiple SMDPPs, which may attract higher pricing if the Teleservice ID is not used as part of the rating model.

[edit] Next Call

Guam meeting preparation call August 30/31. Refer to VSWG Meetings for details.

Main | About | Work Items | Whiteboard | Meetings | Documents
Retrieved from "http://wiki.cdg.org/wiki/20060829_VSWG_Conference_Call_Minutes"
Personal tools
GHRC
OMH