20060913 VSWG Guam Face to Face Minutes

From CDGWiki

Jump to: navigation, search

Contents

[edit] Introduction

A sincere thank you to those that were able to attend the Guam IRT meeting and participate in the Voice and SMS Working Group meeting. We had many new faces in addition to the usual familiar members.

We were able to accomplish several things but could have progressed further on technical issues had we had more technical folks in attendance. While we are no longer a purely technical team, we absolutely need the face to face participation of the hard core technical folks in order to move some of these issues such as SMS, Caller ID, voicemail and plus code dialing forward.

Please contact me (Libby) directly if there are barriers to attendance that I can help you overcome such as providing details on the agenda work items, assisting with travel visas or expressing the need for technical support in more detail.

[edit] Participants

About 40 participants from 20 different companies participated in the Guam IRT VSWG face to face meeting.

  • Aicent, Inc.
  • BTC – Bahamas
  • CDG
  • China Unicom (Macau) Company Ltd.
  • Cibernet
  • EOCG
  • Guamcell
  • Huawei Technologies Co., Ltd.
  • KDDI Corporation
  • LG Telecom
  • Lucent Technologies/Telecom NZ
  • Qualcomm
  • SK Telecom
  • SkyTel (Mongolia)
  • Skylink (Russia)
  • Sprint Nextel
  • Syniverse Technologies
  • Telecom NZ Ltd.
  • VeriSign Inc.
  • Verizon Wireless
  • WorldCell, Inc.

[edit] Discussion Topics

[edit] SMS Billing

Background

  • Summarized currently available solutions:
Bill-and-Keep (serve and home)Available
Serving operator RSP solutionAvailable
Serving operator probesDocumented (in use)
Home operator flat rate roamingAvailable (depends on MC)
Home operator RSP CIBERAvailable
Additional proposed solutions are signaling based billing and MSC CDR billing noted below.
  • Signaling based billing
    • This is a solution aimed at the home operator, to allow them to perform detailed subscriber (retail) billing at a rate specific to the market that served that subscriber.
    • Operators have previously indicated a preference for this over CIBER for home operator retail billing
    • Minimal impact to MC is a key desire for operators
    • Proposal document describes point code based solution - this is believed to be within the current capabilities of most if not all MCs
    • Requires handling of many point codes by RSP.
    • Alternative in document appendix is MAP-layer solution: cleaner (no changes elsewhere in the network, easier for the RSPs, more freedom to choose identifier), if your MC can support.
  • MSC CDR for SMS
    • If we had these, could bill for SMS with CIBER records just like voice
    • One operator had previously requested CDG ask vendors for this. In Miami we suggested both CDG and operators individually ask the vendors, plus coordinated User Group requests.
    • The team needs to determine if this is still required.

Discussion

  • Proposed Point Code Solution
    • VeriSign: Is it really necessary to have so many point codes? Can’t we get one pointcode to represent a particular serving market to all home operators? QC: believe that this is a co-ordination task among national allocation schemes that would be too difficult to achieve and maintain.
    • Question: For GT-routing operators, will MC use pointcode or CgPA in CDR? If it's pointcode, a problem for this approach.
    • It's easy to tell if the MC currently includes the pointcode in the billing record - just take a look! (the proposal changes an existing parameter rather than including a new one)
    • We didn't address the MTP versus SCCP option for pointcode transport in depth. There should be little difference to the operators though.
    • Note that this approach is intended to minimize the MC impact. The tradeoff is routing changes (configuration, not development) in the network. All solutions require some change to the billing system to look for/rate on the new identifier.
  • Requirement for point codes (for the point code solution)
    • Reiterated that operators need to secure a range of pointcodes to represent their RPs and provide these to their RSP.
    • VeriSign: believe that 14-bit (ITU) allocations are tight - this may be a problem for operators to get hold of this many pointcodes.
    • have not heard anything from operators one way or the other.
    • where there are multiple operators in a single country, makes sense for RSP to use a single set of pointcodes in that country to represent foreign RPs.
  • MAP-layer Solution
    • VeriSign: more than one MC vendor known not to support this today.
    • At least one operator understood to be pursuing this approach.
  • New approach
    • See presentation slides
    • custom GT used to carry serving network identity even if pointcode routing used. If GT routing used, extra digits on the end of the address ID the serving network.
    • Easier for RSPs as common identifier can be used. Minimal routing changes in operator’s network.
    • Possible drawbacks identified in slides
    • Usability for MT depends on where the MC gets the information to populate the billing record: from the SMS_Address (in which case we may have a problem as no way to specify in ANSI-41 an address that is not used for routing, unless can override with internal config at MC); or from the OPC/CgPA of the SMSDeliveryPointToPoint Return Result (in which case the custom GT can be provided by the RSP)
  • Which solution should we use?
    • Little interest in new custom GT method - seem to be many unknowns for support in MC and network
    • Benefits for operators seem clear on pointcode solution (although needs to be checked for GT operators).
    • But if it can't be done by the RSPs, or won't be done in a reasonable cost/time, then we have to look at other options
    • From the RSPs, responses are: "we can do it today no problem", and "we will do whatever our customers need".
    • That doesn't seem reason enough to move away from the point code solution in the document.
  • Do we need a common solution?
    • Maybe each operator can just arrange with the RSP to provide the solution that best fits their particular preference/requirement
    • VeriSign: A single solution is easier for the RSPs.
    • Will proceed with trying to come to a common agreement, although this doesn't preclude "side deals" between operators and RSPs.
  • Multiple RSP scenarios
    • How to ensure serving operator information is available to the home operator when each is connected to a different RSP?
    • This was raised on the August 29 conference call, and will be included in an update to the billing document.
    • Since the RSP-RSP communication is not seen by the operators, the RSPs could in theory agree on any means they liked to pass this information between them, then convert it to the "standard" format when signaling on to the home operator.
    • It is presumably less work for the RSPs to use the same point code method that they will use towards the home operator - this should minimize development.
    • The RSP of the home operator will still need to translate the received pointcode into one that is appropriate for use in the home operator's national network, as for a single-RSP scenario.
  • MSC SMS CDR
    • Should we keep(/start) working on this?
    • A CDG-level approach to vendors may be the least likely to yield results as CDG does not buy equipment!
    • Some operators have stated that as a serve, they have no interest in generating CIBER for SMS. (The RSP bulk solution is sufficient for their needs.) So they are unlikely to lend weight to the request (e.g. by committing to purchase a new optional feature)
    • Some operators have also mentioned that they do not want to receive CIBER for SMS as a home. Serving operators that sent CIBER might create problems for these home operators - even if they didn't use the received records for subscriber billing, they would still need to be identified and discarded - i.e. billing system work.
    • TNZ has gone through this process for one of its roaming partners and doesn't recommend it.
    • Syniverse: As a clearing house, we can filter out the SMS-related records, so they would be used to calculate the net financial position, but would not be transferred over to the home operator. Thus no home operator impact necessary after all.
    • None of the operators present expressed a wish to pursue MSC SMS CDRs as a VSWG work item.
    • We will drop this item, but note that the Clearing House capabilities mentioned above mean that there need not be any impact on other operators if one operator chooses to go this route - they are free to raise it with their network vendors.

Decisions

  • The point code solution is favored by those carriers expressing an opinion.
  • Due to lack of interest, exchanging CDRs for SMS billing will no longer be a work item for this group.

Actions

RSP work

  1. Syniverse indicated they will do what their customers request.
  2. VeriSign reports that they can offer this solution now.

Carrier action items

  1. Contact your RSP for this solution
  2. Be prepared to provide one point code per roaming partner you have implemented and plan to implement.
  3. Confirm that your MC includes the far end pointcode in the billing record, OR if you use Global Title Routing for SMS, that the billing record includes the SCCP Called/Calling Party Address for the far end

[edit] SMS Signaling

Background

  • Numerous potential signaling issues are discussed in the SMS Roaming White Paper Click_to_view_or_edit_the_discussion_page.gif(draft Ref Doc #133)
  • Two picked to focus on: SMS Numbering Format, and SMS Message Length.
  • Numbering Format
    • Using indirect routing, the SMS Destination Address is parsed by the home network MC, and must therefore be in domestic format, even while roaming
    • Contrast this to a voice call, where you use the format of the serving network, as the serving MSC analyzes the dialed digits.
    • This can result in customer confusion and lost revenue
  • Message Length
    • Different Maximum lengths in different networks
    • Can result in lost messages, and "message jamming", where one long message prevents all other messages from being received by that subscriber.

Discussion

  • Numbering Format
    • A mitigation approach is to add foreign dialing patterns into the MC's analysis tables
    • One operator noted that (at least in their case) this was a complicated and piecemeal task that didn't fully address all possible messaging scenarios
    • Plus Code Dialing would allow the same format to be used for both voice and SMS
    • A "Virtual Home Environment" type service would also allow consistent usage. In this case SMS is already there as the format is just like at home.
    • A Welcome SMS can be used to inform roamers of the correct format.
    • Other clever ideas are welcome!
Actions
  1. Carriers to add foreign dialing patterns into the MC's analysis tables if you are concerned about this issue.
  • Message Length
    • The maximum SMS message length is not defined at the SMS layer for CDMA - it's a function of limits that apply at lower layers (e.g. SS7, air interface), and is affected by variable-length overhead and optional parameters included. SMEs (e.g. the mobile) and MCs may also impose their own application-layer limits.
    • Standardizing on a useful maximum message length will take time.
    • In the meantime, a failure reporting mechanism is necessary. If you know the message is too long, you can do something about it!
    • ANSI-41 SMS_CauseCode 106 is recommended.
    • The RSP should send this on behalf of the receiving network if the message exceeds a preconfigured length.
    • Multiple methods in use today for Segmentation and Reassembly
    • SCCP SAR is not supported by either RSP today - can we have it please :-)
    • In the meantime, home operators using SCCP SAR should not send segmented messages to roamers - ANSI-41-E defines a way to manage this, or static config in the MC could be used.
    • WEMT is another segmentation method - message segments may be billed as separate messages, but it requires no support from serving network or RSP.
    • Note that ubiquitous support for SAR is not the final answer to length issues: In some cases, a message may not require segmentation in the home network, but be too long for the serving network, even if both supported SAR. SAR on-the-fly by a RSP seems like a difficult proposition - failure reporting is the recommended approach here.
Actions
Carrier action items
  1. Check status of SCCP SAR & WEMT support
  2. Use SCCP SAR & WEMT if you can, if not use failure reporting to SWMS sender
  3. Check MC action on receipt of Cause Code
  4. Don’t send SCCP SAR unless you know it can be handled by the far end
RSP action item
  1. Add SCCP SAR support

Next Steps

The SMS White paper is complete pending any late breaking comments from the team. A conference call with be set seeking approval of the existing document and to set timelines for implementation of the recommendations. I will also seek feedback on what additional steps the team would like to take concerning SMS implementations.

[edit] Caller ID and Voicemail

Background

  • Caller ID is rated #1 priority by operators in 2005 survey with voicemail rated #2
  • Draft reference documents available for both subjects
  • Surveys have been out on both topics for some time. Thanks to China Unicom for responding to the CLI survey and to Pacific Bangladesh, Vivo and Verizon for your responses to the voicemail survey. All others carriers, please respond by October 5.

Discussion

  • Held over for approval as some operators still wish to provide feedback

Actions

  1. Question: how can we encourage/monitor implementation progress?
  2. Carriers respond to the CLI and VM surveys by October 5.
  3. Last call for comments on these two documents. Will review these documents and request approval for the final time the week of October 16. Please have your comments in prior to that date.

[edit] Plus Code Dialing

Background

  • Rated #3 priority by operators in 2005 survey
  • Long-running IRT work item, not a lot of success
  • Network equipment vendor survey results available - a bit of a mixed bag
  • Handset vendor survey circulated to VSWG team for comment
  • Detailed Requirements document under action

Discussion

  • Do we still want this?
    • Increasing use of WorldMode phones makes it (even) more desirable
    • Several operators at the meeting confirmed their interest is still high
    • At least one operator has it as a requirement on all their handsets
    • Will retain as a VSWG work item
  • Handset vendor survey
    • No changes requested by team
    • Will send to vendors shortly after IRT.
  • Requirements document
    • Detailed reqs for MS, MSC, MC, HLR
    • MS section complete, text essentially the same as the survey questions
    • Doc targeted to be available in October for VSWG review.
  • Virtual Home Environment
    • Suggested as a possible alternative to plus code: Use phone just like at home, no need for plus key.
    • Needs more investigation and will be raised as a possible work item for 2007
  • Moving Forward
    • We have not succeeded with plus code so far. Let's not make the same mistakes in this latest effort!
    • A consistent approach to vendors will help - the requirements doc will be the next step

Actions

  1. Carriers please fill out the "who is your vendor" survey. This will help the VSWG coordinate the approaches to vendors, and (as much as possible) enable communication between operators who use the same vendor about what is available when. Results available to date are here.

[edit] CIBER Migration Document

Background

Discussion

  • Needs to be put in CDG format.
  • RSPs can convert the format for carriers but they cannot add the missing information.
  • By mutual agreement, carriers can continue to exchange X0 records with a partner. Must discuss this with the RSPs and each partner.
  • Document describes the pros and cons of migrating to X2 record types as well as the possibility of billing the wrong carrier or sub if X2 records are not populating properly.
  • KDDI noted that many Asian operators still use X0 records. KDDI requests that operators please read the document and comment on it.
  • VeriSign requested the terms be edited for consistency in the document.

Decision

  • Approved by VSWG pending CDG reformatting and addition of the following language and some editorial suggestions from VeriSign.
    • Clearinghouse should test operator’s CIBER 2.5 records in clearinghouse's test environment
    • Clearinghouse should work with operators throughout the test.
    • Operators should be able to test unlimited files.
    • Certification certificate can be provided if needed. (this applies to clearinghouse certification, not carrier to carrier certification)

Action items

  1. All carriers who haven’t had a chance to comment please do so now.
  2. Libby – incorporate new verbiage from VeriSign and KDDI and send to technical writer for reformatting.
  3. Libby - Send final document to plenary for final approval
  4. Cibernet, RSPs, CDG and carriers: communicate to customers/partners that this paper exists.

[edit] Coverage Exchange Initiative

Background

  • Rated #5 priority by operators in 2005 survey
  • Carriers requested an efficient way to exchange coverage information

Discussion

  • Offer a basic upload, download section on the CDG website for coverage and other documents carriers want to exchange.
  • This file service can be utilized for documents other than maps like RPQF and TDS.
  • Consider if fixed line CDMA carriers should be included in the tool although they don’t currently do much roaming.
  • A separate login will be required to access the coverage exchange site to ensure security of carrier info is preserved.
  • Public maps as well as non public information such as attribute information would be posted on the site. Carriers decide what files they wish to provide to which carriers.
  • Carriers requested notification of new files posted. Libby to review with developers but cannot promise this functionality at this time.
  • Carriers noted that they won’t allow lack of participation in this tool to hold up progress so may continue using the old-fashioned email way to exchange info in parallel
  • Carriers noted per company login is not very secure and may prefer individual logins or admin structure.
  • Will have access controls in place to ensure information is only accessible to those designated by carriers.
  • This solution is basic and achievable with no additional cost to carriers
  • Developers expect this can be done before the next IRT
  • This does not preclude work on a more advanced solution

Actions

  1. Libby to continue work on the basic solution while the team moves forward with work on a more functional solution.
  2. Libby ask developers about notification emails, per user logins or admin functionality.


[edit] Technical Data Sheet

Background

  • Need a standardized Technical Data Sheet (TDS) using common terms and a common format so we are updating the existing document #81.
  • PRL and SMS tabs were approved during the June 2006 meeting

Discussion

  • Team member suggestions
    • TDS training
    • Suggested that the CDG consult with new carriers to ensure their TDS conforms to the new standardized format
    • Add IRM and MDN conflicts to TDS and to the carrier qualification form as well as the requirements document. Also notify IFAST if a conflict is discovered.
    • There was lots of discussion about where to put the conflict information.
    • This is fairly static information but different groups see different docs so decided to include it in both places.
  • PRL and other automated tools can be utilized if the format is standardized.

Decisions

  • KDDI, Sprint and SkyTel agreed to begin to use the document.
  • Other carriers need time to review the document before agreeing to use it.
  • Verizon can’t yet agree to using the new format but will try to use the same column headers to ease confusion.
  • Add IRM and MDN conflicts to the numbering tab of the TDS and the RPQF.
  • The CDG will consult with new carriers to ensure their TDS conforms to the new standardized format. A carrier mentor TDS review was also mentioned.

Actions

  1. QC to look into TDS training
  2. The CDG will consult with new carriers to ensure their TDS conforms to the new standardized format
  3. Review of remaining tabs of TDS by SMEs in late September
  4. Complete “how to” word document after spreadsheet is complete
  5. Carriers begin to use new format 3 months after final format is agreed upon (timeline pending approval by team)

[edit] Mobile Equipment ID

Background

Discussion

  • KDDI Issue
    • When both UIMID and MEID are available, which one goes in CIBER "ESN" field?
    • Arguably applies to a UIM in a non-MEID handset as well, so a UIM issue rather than a MEID one?
    • Nevertheless, some additional text for the MEID document was presented (see slides)
    • KDDI/QC also working on some additional clarifying text for the CIBER manual
  • Wider implications
    • With the introduction of MEID and (MEID-based) EUIMID, and the associated backwards compatibility identifiers (e.g. pESN), there are a number of ways to populate ANSI-41 messages. It may be possible for the serving network to do so in a way that confuses the home network.

Actions

  1. QC to follow up with standards bodies to see if there is a need for additional standards text.
  2. QC to work with KDDI on CIBER manual language and solicit comments via the wiki.

[edit] Agreements document

Background

  • CDG Document #44 – CDMA International Roaming Agreement was last updated June 2005

Discussion

  • Document may need to include more text for the following topics:
    • Packet Data: 1x and EVDO
    • Interstandard: Point to Document #127
    • Incomplete Calls, being billed for them
    • Text covering multiple properties
    • SMS

Action

  1. Conference calls will be coordinated to discuss updates. Contact Sara Aab to contribute.

[edit] New Projects

  • Roaming Service Quality kicked off September 2006, Lead by Kyoko Uchida from KDDI, Contact Kyoko to contribute
  • Prepaid Roaming November 2007, looking for sponsors for this project, Contact Daniel Salek to contribute
  • Hold on starting additional new projects until others are finished up and priorities are reevaluated for 2007

[edit] Improvement suggestions for VSWG

Background

  • Time to take the pulse of the group and see how we can improve VSWG efficiency and effectiveness.

Discussion

  • EOCG – List of network numbers/IDs that must be applied for would be useful.
  • Carriers requested more individual follow up on outstanding action items as well as adding a calendar to the wiki to see when things are due.
  • Reduce the number of work items in progress at once. Too much to get done all at one time.
  • Difficult for non native English speakers to follow conference calls. CRMs to ensure carriers understand the issues with one on one meetings.
  • Carriers requested web conferences in addition to conference calls so key words can be typed and read during call for ease of understanding.
  • No interest expressed in translated documents or on site translators for conferences.
  • Responses to consider adding voice bridge to face to face meetings.
    • Concerned that technical difficulties may detract from meeting as well as incompatible time zones.
    • Meetings would have to maintain a rigid timeline if voice bridge is added.
  • Have more conference calls during each quarter and work fewer items. This may result in less time required for working groups at quarterly IRT meetings.
  • Schedule more time for carriers to organize their own meetings with other carriers.

Actions

  1. QC to investigate implementing suggestions above and will report back to the team on feasibility of each suggestion.

[edit] 2007 Priorities

  • The list of suggestions from 2006 will be used as a starting point. I am looking for additional suggested work items for 2007.
  • VSWG 2007 priorities will be reported on during the November IRT but we will not start work on 2007 priorities until 2006 are cleaned up or thinned out.
  • Contact Libby to suggest work items or to join the team.
Main | About | Work Items | Whiteboard | Meetings | Documents
Retrieved from "http://wiki.cdg.org/wiki/20060913_VSWG_Guam_Face_to_Face_Minutes"
Personal tools
GHRC
OMH