20060621 VSWG Miami Face to Face Minutes

From CDGWiki

Contents 1 Participating Companies 2 Meeting Documents 3 Discussion Topics 3.1 SMS Roaming Test Plan 3.2 SMS Roaming Partner Qualification Form 3.3 SMS Roaming Billing 3.4 SMS Length issues 3.5 Voice Mail 3.6 Caller ID 3.7 Standardized TDS 3.8 X0 to X2 CIBER record type migration 3.9 Status reports 3.9.1 Roaming partner coverage exchange initiative 3.9.2 Network based + code dialing infrastructure vendor survey 3.9.3 Carrier reports on the broadcast of IMSI 11_12 (MCC MNC)

[edit] Participating Companies

African CDMA Forum	QUALCOMM
Alltel	QUALCOMM China
Bahamas Telecommuncations Company	S Telecom Vietnam
Caribbean Cellular Telephone	SK Telecom
CCG	Speenet Communications
Centennial Dominicana	Sprint Nextel
China Unicom	Syniverse
Cibernet	Telecom New Zealand
Digicel Jamaica	TELUS
Guamcell	TRICOM
Haitel	Telecommunications Services of Trinidad and Tobago
Huawei	VeriSign
Iusacell	Verizon Dominicana
KDDI	Verizon Wireless
LG Telecom	Verizon Wireless Puerto Rico
Lucent Technologies	Vodafone NL
Pakistan CDMA Forum	VSNL International
Pelephone	w2bi, Inc.

Almost 80 people participated in the Voice and SMS Working Group in Miami. SMS, caller ID, voicemail, + code dialing, X0 to X2 CIBER record type migration and the coverage exchange initiative were all discussed as well as the carrier reported status of enhanced PRL. Several things were accomplished as you can see from the notes below.

[edit] Meeting Documents

See the CDG IRT website for documents presented at the meeting.

[edit] Discussion Topics

[edit] SMS Roaming Test Plan

• The SMS Roaming Test Plan (CDG Reference Doc #134) was approved by the Working Group and by the Plenary the next day.

• TNZ, Pelephone and Sprint volunteered to act as initial users of the document, and will report back to the team on their success or otherwise.

• Next steps
  • Seek approval of the document by the board.
  • Target date for the carrier reports on using the test plan is the September IRT meeting.

[edit] SMS Roaming Partner Qualification Form

• This document (CDG Reference Doc #132) was approved by the working group, pending conversion to CDG standard format, and the addition of some administrative information (e.g. carrier name) at the start of the form. The sample answers that were displayed at the meeting will be included as an appendix to avoid confusion.

• A separate document will provide additional explanatory information about the individual form fields.

• Next steps
  • Seek approval of the reformatted document by the board.
  • Carriers fill out the RPQF and exchange with roaming partners.
  • Target date for carrier reports on using the RPQF is the September IRT meeting.

[edit] SMS Roaming Billing

• A number of carriers have pointed to billing as being a major limitation that has prevented them from implementing this service. Accordingly, SMS roaming billing has been a key focus for the VSWG this year.

• Background
  • General billing requirements:
  1. The serving carrier wishes to be paid for providing SMS service to inbound roamers
  2. The home carrier will generally charge the roamer
  3. The home carrier wishes to cover their costs (including the intercarrier settlement component)

• Possible solutions:
  • For the serving carrier
    • Bill and Keep (serving carrier is not paid for inbound roaming SMS) - available now with no effort
    • Bulk billing (agreed SMS rate applied to total number of SMSs, summary invoice or direct application to net settlement position) - available today from both RSPs.
    • Generation of individual billing records in the serving network (which are then transferred as CIBER records) - in use by some carriers today, but most serving carriers cannot or do not wish to generate per-SMS records.
  • For the home carrier
    • No special roaming charge. No way to cover any intercarrier charge. SMSC billing record used as per normal. Available now with no effort.
    • "Flat rate" roaming charge. Same rate charged for all roaming SMS, regardless of location. SMSC billing record includes RSP point code. Home carrier sets rate to at least cover average expected intercarrier charge. For most carriers should be available today with minimal effort in the network.
    • Destination-specific charge, delivered via CIBER. Home carrier uses received CIBER record (instead of or as well as SMSC record) to bill subscriber. If serving carrier generates CIBER, these records are available to the home carrier today with no additional effort (although billing system changes may be required to process them). See below for discussion on RSP-generated CIBER.
    • Destination-specific charge, information received via signaling. SMSC receives enough information to generate a billing record which identifies the serving carrier. In many cases today, the fact that the signaling connection is via an RSP means that there is no information in the SMDPP received at the SMSC that identifies the serving carrier. See below for further discussion.

• Discussion
  • MSC-generated billing records
    • Some operators have requested a CDG approach to MSC vendors asking them to develop billing records for SMS. Currently not all operators would be interested in such a feature. We discussed the CDG's role/ability to influence vendors, and settled on a three-pronged approach: a CDG/IRT approach to vendor contacts, individual carrier approaches, and also assisting operators to make a coordinated request at the relevant vendors' User Group meetings.
  • RSP-generated CIBER
    • As previously advised, both RSPs have announced their ability to generate CIBER records from the ANSI-41 SMS signaling that traverses their systems. At the meeting it was clarified that while the solutions are "available" in that no development is required, some configuration work would be necessary to meet the specific CIBER record field population rules of the receiving (home) operator once the decision is taken to implement the solution for that operator.
  • Bi-directional SMS billing. Although many operators do not charge (either as home or serve) for MT-SMS, it was noted that since some operators do (or would like to) charge for MT-SMS, solutions defined by the VSWG should allow for MT-SMS billing as well as MO.
  • Signaling-based solution.
    • The discussion focused on which parameter in the signaling message could be modified or inserted by the RSP to identify the serving carrier. A document was previously circulated proposing two different solution options: a MAP based approach using the SMS_ChargeIndicator, and a transport-layer approach using a "dummy" point code in MTP. Prior to the meeting the preferred MAP option was changed to the SMS_OriginatingAddress (SMS_OA) parameter.
      • Advantages of the MAP-based approach:
        • Simple for the RSPs to implement. This is the layer at which the RSPs can already modify parameters.
        • "Safe", in that no other network elements need to be aware of the change, only the SMSC.
      • Disadvantages of the MAP-based approach:
        • Complex for carriers/SMSCs. It is not clear which MAP parameters SMSC vendors currently include in their billing records, but this is expected to vary. Development may be required to support a common solution. Widespread support may be slow due to multiple SMSC vendors affected.
        • Message length increase. If the SMS_OA is not present in the SMDPP from the serving carrier, this parameter will be inserted by the RSP, with an expected minimum length of 10 bytes. This may cause a long SMS which would have otherwise been successful to fail as overlength.
        • Overwriting. Although the best information available currently indicates that no carriers look to the SMS_OA to carry some other important information, it is possible that some operators may require other information in this parameter.
        • Asymmetrical. Would require a different parameter for MT SMS as compared to MO.
      • Advantages of the transport-layer approach:
        • Simple carrier implementation. Many carriers' SMSCs already include the point code in their billing record. There may be no SMSC modification at all required if this point code is changed to be serving-carrier specific.
        • Common for non-RSP implementations. With no RSP in the middle, expect that the native point code could be used to identify the serving network. This may require a large administration effort in the home billing system, but the principle is there to use the same approach whether or not an RSP is used.
        • Inclusion of the "dummy" point code in the SMS_Address MAP parameter at registration time could allow this approach to be used for MT billing as well.
      • Disadvantages of the transport-layer approach
        • Complex implementation in the network. Routing needs to be defined for the dummy point codes through all the STPs etc that may handle the message.
        • Different for GT. Where a carrier uses Global Title Translation (GTT) for routing in their network, a "dummy" SCCP Global Title should be used instead of a point code. This represents an impact to the RSP to support the various options.
        • Complex implementation in the RSP. The RSPs need to manage many point codes, and determine the point code they will appear as towards the home carrier based on which serving carrier sent them the original message.
        • Point code availability. Several parties have raised the issue that it may be difficult to secure point codes in each network/country to represent all other roaming partners. Apparently in some countries (especially those using a 14-bit point code) there is already an issue with exhaustion of this resource, due to inefficient assignment procedures.
      • Comments on the transport-layer solution
        • All those carriers who voiced an opinion preferred the transport-layer approach, citing the various advantages listed above. Carriers (who would presumably be responsible for securing point codes from their national assignment authority to represent their international roaming partners) did not express any opinions about the difficulty or otherwise of obtaining point codes.
        • A point code can be carried in both the MTP and SCCP layers. Which one should we use? A point code in SCCP should be ignored by STPs, minimizing the impact on the signaling network, however this SCCP point code may be mapped into the MTP when building a message reply, so it would still need to be routable in this case. If the two point codes are different, which one will the SMSC include in its billing record?
        • Multiple Solutions - it was noted that although the group is aiming for a single signaling-based solution, there is nothing to prevent a carrier from working with their RSP to implement a different approach. A single solution is preferable from a time-to-implementation perspective but is not mandatory.
        • Why Bother? - Some operators noted that the discussion and complexity around this issue may not be worth the effort. The "flat roaming rate" approach can be simple for customers and operators alike
        • Other operators reiterated their desire for fully-differentiated billing.
      • Decisions and Next Steps
        • Transport layer approach is the preferred option
        • For those carriers that use point code routing, this will entail the use of dummy point codes that route to the RSP, but represent the serving carrier. For carriers using global title, the same function can be performed by SCCP Global Titles.
        • QUALCOMM to investigate the impacts of using point codes at SCCP rather than MTP and report back.

[edit] SMS Length issues

• Some carriers have reported difficulties when sending long messages to other networks. Messages that would be successful on their own network fail when sent to one of their subscribers who is roaming.
  • Two different issues can be identified here:
  1. Support for SCCP Segmentation and Reassembly (SAR) is not very widespread today, but some operators do use it.
  2. In some cases, even unsegmented messages that can be supported in one network are failing in another.

• Discussion
  • It is difficult to identify an "official" maximum length for SMS messages. Typically the maximum length is determined by the underlying transport, and is affected by the type of addressing and the inclusion of optional parameters.
  • ANSI-41-E (through incorporation of N.S0020) adds support for SCCP SAR. The MSC can report its ability to support SAR by setting a bit in the TRANSCAP. The HLR can provide this information to the SMSC in the smsreq.
  • ANSI-41 provides an SMS_CauseCode value (106) for "User Data size error" which could be used to indicate an overlength message failure.
  • Some SMSCs experience "message jamming": if an overlength message is submitted for delivery to a subscriber, no subsequent message of any length can be delivered to the subscriber until the long message expires, which can take several days.
  • There is no such thing as "SMS SAR", i.e. segmentation at the IS-637 level, for the normal Cellular/Wireless Messaging Teleservice.
  • Wireless Enhanced Messaging Teleservice (WEMT) is a means to carry GSM Enhanced Messaging Service (EMS) over CDMA SMS. The EMS protocol does define a SAR scheme.
  • The RSPs could in theory divide a single long message into multiple SMDPPs if the message length exceeded a previously configured maximum for the receiving network. This is different to SCCP SAR, and would be a non-trivial task for the RSPs. Issues like MESSAGE_ID conflict may cause problems.
  • Bidirectional issue? Most of the time we think about an SMSC sending a long message MT to a mobile. Is it possible to encounter problems with MO-SMS as well? Can a mobile send a message that is too long for the air interface? Can an air interface message be too long for #7?

• Recommendations
  • Operators who use SCCP SAR for SMS are encouraged to report this in the MSC TRANSCAP parameter, and to make sure that their HLR relays this information to the SMSC. The SMSC should not send a segmented message to a network element not known to support SAR. Use of a single RSP MSCID may limit the usefulness of this approach.
  • Operators who do not currently support SCCP SAR are encouraged to add this support.
  • Operators who receive an overlength message are encouraged to respond with the SMS_CauseCode described above. While this won't help the long message, it should enable the SMSC to avoid the "jamming" problem. The RSP may be able to apply this treatment if the receiving network can't.
  • Operators whose mobiles support WEMT may consider this form of segmentation. It is largely transparent to the RSP and serving MSC.
• Next steps
  • Carriers will be asked what method they use to deal with over length messages. Note that the results of an earlier survey on SMS length are available here.

[edit] Voice Mail

(Draft) Reference Document #135 was introduced. Specific items are covered below

• Voicemail deposit
  • The document strongly recommends that "optimal routing"/RedirectionRequest is used to forward calls to voicemail from the home network and never from the serving network.
  • This approach is widely used by carriers today
  • No dissenting opinions were voiced

• Voicemail indicator
  • Two major notification methods are described in the document:
  1. "ANSI-41" (MessageWaitingNotificationCount and MessageWaitingNotificationType parameters and air interface Feature Notification or Flash With Information Messages)
  2. "SMS" (SMDPP/Data Burst with Voice Mail Notification teleservice)
  • Operators typically use a single method in their networks. Both the ANSI-41 and SMS methods have operators using them today.
  • In general, support for either of these methods does not demand too much from the serving network. However, some serving operators are known not to support the ANSI-41 method, and others do not yet have Mobile Terminated SMS roaming in place with all partners.
  • Both RSPs agreed to look at the possibility of conversion between the ANSI-41 and SMS methods to solve the above incompatibility problems.
  • The document recommends that operators use the ANSI-41 method. This recommendation is based almost entirely on the concern that the SMS-MT roaming footprint for an operator may not match that for voice. If SMS is known to be available, the SMS method of notification may provide other benefits (more information about the original caller, callback number for easier access).

• Voicemail access
  • The document makes a short term recommendation that operators support each other's short code access numbers for voicemail access. Various methods of achieving this support are included.
  • Some operators tell their customers to dial their own number for mailbox access. In some cases this is coded into a single button press on the handset. Further investigation is required on how to enable this method for roaming. A Revertive Call trigger (if supported by the serving MSC) may detect this call, although it is unknown how this will work if (as is recommended elsewhere) an E.164 MDN is used while roaming.
  • The long term recommendation for the correct delivery of CLI to the home network (support of ANSI-41 Voice Message Retrieval service) seems unlikely to be ever deployed. Some operators did however believe that international/long distance providers could be managed to preserve CLI for the call back to the home network. Operators are encouraged to investigate the chances of enforcing this requirement.
• Next steps
  • Daniel to update the paper with decisions made in Miami.
  • Additional research and conversation required on revertive calling.

[edit] Caller ID

(Draft) Reference Document #139 was introduced. Specific items are covered below

• This was the #1 ranked work item in the carrier survey. Correct Caller ID display is assumed to stimulate call revenue.
  • Roamer Terminated Caller ID.
    • This is believed to be the highest priority call direction for support of Caller ID
      • Two methods are possible for delivery of the Calling Line Identity (CLI) to the serving MSC
        1. via ANSI-41 (LOCREQ + ROUTREQ)
        2. ISUP (call delivery leg to TLDN)
    • Use of the ANSI-41 method is recommended to avoid issues with unreliability of CLI transport in international ISUP legs.
    • The home and serving networks, and optionally the RSPs, may have roles to play to format the number for the greatest ease of return. Ideally (and as per IS-875) the displayed digit string should require no modification to return the call while the roamer is located in the country in which the initial call was received.
  • Roamer-originated Caller ID
    • Full support of Roamer-Originated Caller ID (including a call back to the home country) can have other benefits, e.g. simplification of voicemail access.
    • The first step is the support of an E.164 international MDN. The RSPs may be able to internationalize the MDN sent by the HLR, but the MSC should still support it.
    • Careful coordination in the serving country with the international gateway exchange and other networks may be required to ensure that the international MDN is correctly and safely transported in the serving country and for international calls.
• Next steps
  • Determine how carriers generally deliver caller ID now as well as which carriers use an E.164 MDN.

[edit] Standardized TDS

• The VSWG finalized the SMS and PRL tabs of the voice and SMS Technical Data Sheet. This work is to improve the integrity of the technical data which must be exchanged to implement voice and SMS roaming.
  • The team requested two additional fields on the SMS tab which are maximum message length and vendor software version.
  • The team requested a change to the PRL tab to clarify which channels must go into a roaming partner PRL and which channels were not required.
  • The joint session between the VSWG and PaDIRT decided the EVDO system selection information would remain on the packet data TDS and would not be replicated on the voice and SMS TDS.
• Next steps
  • Reissue the TDS with these changes. Target date July 14.

[edit] X0 to X2 CIBER record type migration

• Training was provided by Cibernet concerning how to properly populate an X2 record type. This was requested by carriers to ensure a smooth migration from X0 records to X2 records. Gepsie’s presentation is posted on the CDG website along with the rest of the documents from the June IRT.
• Gepsie Cox of Cibernet is authoring an educational paper which requires input from the team. A subgroup is being formed to focus on this topic. Please forward the name and email address of a person from your company who will assist with this billing focused subgroup. Copy Gepsie at gcox@cibernet.com and Libby at lmackay@qualcomm.com.
• Next steps
  • A conference call will be held for the subgroup to move forward. Action – please forward the name of your company’s representative per request above.
  • A recommendation for testing the success of the migration was also presented by KDDI. This should be discussed within the subgroup and potentially wrapped into the paper.

[edit] Status reports

Reports were given on the following topics which are available to view on the roaming section of the CDG website:

[edit] Roaming partner coverage exchange initiative

• KDDI suggested that the team focus first on how the information will be exchanged versus what will be exchanged.
• During the last CEI subgroup meeting (pre IRT) it was decided that the requirements should be compiled for the subgroup to look at.
• Next steps - A meeting will be held no later than late July to review the requirements which the lead, Travis Lathrop, compiled and consider how to best move forward.

[edit] Network based + code dialing infrastructure vendor survey

• The results of this survey are posted on the CDG website in the roaming section. The overall response rate was good although I am still waiting on responses from Ericsson and Samsung. Please review the responses from each vendor carefully as a yes answer may not mean yes for your company. While Huawei and Lucent both support this feature, the Lucent solution will have billing impacts for some carriers.
• There was much debate over how to get vendors to support this feature. It was suggested that this be worked from a variety of angles. Nancy from Telus suggested carriers get involved in their vendor user groups and voice their preferences that way. The carriers requested the CDG get more involved in influencing vendor activities. While this is less effective (the CDG doesn’t purchase infrastructure) we heard the request and are discussing how to best do this.
• Next steps
  • Bruce from Lucent will draft the handset vendor questionnaire.

[edit] Carrier reports on the broadcast of IMSI 11_12 (MCC MNC)

• The updated report is posted on the CDG website. If your company is not included or the report is not up to date, please forward your update to Libby.
• Next steps
  • Continue to solicit carrier status.

Conference calls will start up again shortly with the first calls focusing on the Coverage Exchange Initiative, the X0 to X2 CIBER record type migration, Calling Line ID and Voicemail.

We are doing background research on a few of the upcoming priorities so we are ready with the information when the top tier priorities are complete. Per the priorities set by the team, the next projects are authentication, quality of service and prepaid roaming. Until then, we still have plenty of work to do on existing projects so I encourage you to review the notes, visit the wiki to see the latest progress and participate in the upcoming calls.

Main | About | Work Items | Whiteboard | Meetings | Documents