20060411 VSWG Conference Call Minutes

From CDGWiki

Jump to: navigation, search

Call Date/Time:

Tuesday, April 11, 2006 17:00-18:30 PDT

[edit] Participants

The following companies attended the call:

  • Alltel
  • CDG
  • China Unicom
  • Oceanic Jamaica
  • QUALCOMM
  • Reliance
  • Sprint Nextel
  • Syniverse
  • VeriSign
  • Verizon

[edit] Agenda & Discussion

  • March IRT recap

    • Over 50 people attended the VSWG meeting at the March IRT. Time was short so we only got through 3 of our top priorities. Please see the notes from the meeting posted on the wiki.

  • Detailed review of the SMS white paper - The main event. Please DO bring your SMS experts. Plan to make team decisions on the call on the following topics:
    1. Review key outcomes of Cabo discussion:
      • Bill and Keep is not acceptable as a long-term billing strategy for international roaming
        Comments:
        Verizon would like to keep this option "on the table" (including remaining in the white paper). It may be acceptable for some operators in some scenarios.

        QC: Retaining Bill-and-keep doesn't represent any additional work for the team as there is no need to deal with charging by the serving carrier, and therefore no need for the home carrier to be able to charge the roaming subscriber a different rate.

      • Carriers are interested in being able to easily identify the true serving network identity. Note that today, depending on interconnection method, the problem can be either not enough information, or too much! The assumption at present is that the level of granularity required is to a country/carrier level only
      • Many carriers prefer to receive this information as part of the existing SMS signaling (rather than in a billing record)
    2. MT-SMS
      QUESTION: Do carriers require identification of the serving network for MT-SMS as well as MO? A possible reason would be if some roaming partners charged for MT-SMS and others didn't.
      Comments:

      Verizon: "Require" is too strong a term, but interested in finding ways to support this
      Sprint: Also interested in being able to do this
      QC: OK, proceed with the assumption is that this is something we should include in what we are trying to achieve

    3. Recap SMS survey response
      Some home carriers wanted to receive CIBER records for SMSs to/from their roaming subscribers, others didn't!
      QUESTION: Please be prepared to say if your company wants to create and/or receive CIBER or specifically do not plan to/will not create and/or receive CIBER.
      Comments:

      Verizon, Sprint, Alltel: don't want to receive CIBER
      Reliance, Oceanic Digital: yes interested to receive CIBER (Oceanic: in the interests of achieving a unified solution, not an absolute requirement)
      Action:
      QC: Follow up with other carriers that responded to the initial survey to confirm their position is still the same

    4. Proposed approach
      QUESTION: Should the VSWG work to progress both billing- and signaling-based transfer methods for the serving network ID?
      Comments:

      QC: In the absence of a real quorum of carriers on the call, and pending the above action item, assume yes. Note that current discussion is focusing on ways to satisfy the home operator desire for serving carrier identification. Assumption is that current RSP offerings can address the serving carrier's wish to receive payment for providing SMS service to inbound roamers. If this is not the case, please advise!
      Reliance: What about carriers that direct connect without an RSP? QC: In short, they are on their own! Options for the serving carrier include bill-and-keep, MSC CDR production (in the rare cases where that is currently possible), or deployment of a network probe to gather information for CIBER generation. For the home carrier, direct connect implies that the serving carrier should be readily identifiable from the transport layer of the SMDPP messages.
      QC: Current thinking is that although there may be two solutions (signaling & billing) that get deployed, it should be possible for one carrier to use one method exclusively, irrespective of their roaming partners' preferences. This sounds too good to be true, but is based on the assumption that the RSP can provide either billing or signaling information to the home carrier without dependence on the serving carrier's capabilites. Exception is the (currently rare) case where the serving carrier generates CIBER on their own. If the home carrier doesn't want to receive it, me may have a problem (although they could still use MC for subscriber billing, discard SMS CIBER, but pay the settlement that was generated from that CIBER)

    5. CIBER solution
      Some carriers want this. Should we work to define some common record type 22 field population rules for SMS? This should simplify the requirements for whoever (e.g. RSP, serving carrier) is generating the CIBER records.
      QUESTION: Is there anything else the VSWG can do to advance the availability of CIBER for SMS Roaming?
      QUESTION: How to handle other Teleservice (e.g. VMN)?
      Comments:

      Syniverse: Note that nothing prevents an operator which is currently capable of generating CIBER in their network for SMS from sending these records. Existing CIBER standards can accommodate SMS. For RSP-generated CIBER, home network billing systems likely to have differing requirements. Unlikely to be able to arrive at a consistent set of rules that will satisfy everyone - instead will have to do custom builds per home. Note that RSP generation of CIBER is provided for the home operator only - it is not part of net settlement. QC (afterthought) - but couldn't the records be sent to the serving operator, for them to submit back to their clearinghouse and so they will become part of the intercarrier settlement?
      QC: Generation of CIBER from ANSI-41 SMDPP message may mean that some of the record fields can not contain as detailed information as might be available in voice.
      Reliance: What can the CDG do to encourage MSC vendors to add CDR generation for SMS to their switches?
      Actions:
      QC: Contact carriers interested in receiving CIBER (many of whom were not on the call), see if they would like assistance with this
      QC: Investigate CDG-level effort to seek MSC SMS CDR capability. This may be something that needs endorsement from a group of carriers who would want to deploy this capability

    6. Signaling approach
      QUESTION: What information do carriers' MCs include on their billing records today that could be used to identify the serving network? Even if the information present today doesn't ID the network, it's useful to know where we could recommend changes and be sure they were captured in the CDR.
      ACTION: For the list below, please indicate which fields are currently included in your billing records. Possible fields include (For MO SMS):
      • Originating Point Code (MTP)
      • Calling Party Address (SCCP)
      • SMS_OriginatingAddress (ANSI-41)
      • SMS_OriginalOriginatingSubaddress (ANSI-41)

      (For MT SMS):

      • Destination Point Code (MTP)
      • Called Party Address (SCCP)
      • SMS_Address (ANSI-41)
      • SMS_DestinationAddress

      Any other fields that could be used? Some late-breaking suggestions are SMS_ChargeIndicator, and for MT-SMS, MSCID in the smdpp

      Comments:

      Reliance: Use SCCP Calling Party Address. Easier for MC vendor to process (compared to MAP-layer changes), should not be a problem to include in MC CDR
      QC: Need to be careful if assigning true serving MCC+MNC in SCCP CgPA. If you have any other MCC-based translation in your STPs/SCCP Relays, the return result may bypass the RSP! Reliance: we would just point all MCCs to the RSP - we don't have any other use for E.212 global titles
      Sprint, Alltel, Verizon: Work in progress to determine MC capabilities. In at least one case, MC vendor is asking "where would you like the identifier to be?"
      Syniverse/QC: Transport-layer manipulations may have unforeseen side effects on message routing. MAP-layer modifications are more contained "inside" the message. [General discussion on potential routing arrangement for a transport-layer identifer seemed to suggest it could work]
      Actions:
      All carriers interested in signaling approach: Progress discussions with MC vendors on preferred part of the SMDPP to contain the serving network identifier
      QC (decided after the meeting that it might be a good idea): Prepare a "straw man" proposal with 2 options - 1 MAP layer, 1 transport layer way to carry this identifier

    7. Whitepaper feedback
      • Any comments on the paper?
        None received

        Action:
        All: Provide feedback on anything in (or missing from) the document as appropriate.

      • Quick coverage of some of the signaling issues, esp. Numbering Formats, and Message Length.
        ACTION: Please ensure you are prepared to discuss and provide opinions on section 7 of the white paper
        Comments:

        QC: Highlighted two issues for the team's attention when implementing SMS roaming:

        • the fact that (for indirect routing) the destination address must be in a format acceptable to the MC in the home country, as opposed to voice where the dialed digit format is as for the serving country.
        • The possibility of different maximum message length limits imposed by the home and serving network. The recommendation is that messages be rejected (with a "too long" indication) rather than truncated.

[edit] Next Meeting

Date Change: Next meeting approx May 9, topic for discussion:

  • Coverage map exchange
Main | About | Work Items | Whiteboard | Meetings | Documents
Retrieved from "http://wiki.cdg.org/wiki/20060411_VSWG_Conference_Call_Minutes"
Personal tools
GHRC
OMH