1

MMS-Voicemail InterworkingSpam/Fraud Control

Relationship with NFCC & Content ScreeningAlex Gogic – Randall Gellens

v041018.0

2

MMS Work Overview (1 of 3)

Status• Stage 1 published MM/YY (S.R0064-0)

• Stage 2/3 published MM/YY (X.S0016) multipart document– Several MM1 (client-server) interface variants: OMA/WAP, M-IMAP,

SIP-based

– MM3 - Internet mail exchange interface

– MM4 – Inter-carrier interworking

– MM7 – Value-Added Service Provider interworking

• Transfer to OMA in principle OK with 3GPP2 SC, but– Some reluctance on 3GPP’s part

– Likely transfer will occur anyway, but potential for delay

– Still need to hash out the details, come to final agreement– Again, more delays likely

– Transfer agreement (from joint London meeting) says both 3GPP and 3GPP2 are expected to continue MMS development until xfer– 3GPP has been doing so -- why not 3GPP2?

3

MMS Work Transfer to OMA

In principle OK with 3GPP2 SC, but

• Some items with the new OMA terms may be problematic– May not apply retroactively

– Subject of SC discussion October 11 and in Shanghai

• Some reluctance on 3GPP’s part– Likely transfer will occur anyway, but potential for delay

– Unclear if existing 3GPP work will be transferred

• Still need to hash out the details, come to final agreement– Again, more delays likely

– Transfer agreement (from joint London meeting) says both 3GPP and 3GPP2 are expected to continue MMS development until xfer– 3GPP has been doing so -- why not 3GPP2?

4

MMS Work Overview (2 of 3)

MMS Revision A• Stage 1 published May 2004 (S.R0064-A)

• Stage 2/3 development on-going – baseline text

• Intent to align with 3GPP features in Release 5 and 6, so as to smooth eventual transfer to OMA

New Features• Imbedded links – currently in baseline

• Digital Rights Management for MMS content – in baseline

• Value-Added Service Provider (VASP) interface and features (e.g., short code addressing) – partially in baseline

• Management/Control of network-based repository – in baseline

• Conditional delivery (e.g. roaming status, excessive size, originator ID, …) – partially in baseline

5

MMS Work Overview (3 of 3)

MMS Revision B• New Work Item kicked off July 2004

• Spam control features

• Fraud control features

• Messaging Interworking, in particular with Voicemail

• OMA will inherit this work upon transfer

• Continuing evolution shows MMS market appeal

• Especially for spam control, need to have standards ASAP– Long lead time for products

– Can’t wait until operators are hit with problem

6

MMS-VM Interworking Motivations

Motivation 1: Improve quality and features of voicemail• Transmission losses can be eliminated for a more understandable

message• Transcoding can be considerably reduced• Better reliability – e.g. no dropped calls during message recording or

retrieval• Improved features in message submission, e.g. “pause” button, “push

to record”, pause erasure, etc.• Voicemail can be given a multi-media dimension (e.g. personalized

greeting with a photo)

Motivation 2: Improve radio network efficiency for voicemail • Studies show that radio network cost to deliver voicemail can improve

threefold if MMS is used– Outline of an analysis provided in subsequent slides

• The overall net effect on radio network dimension depends on relative voicemail load– Can be as high as 5% for a voicemail load of 10%

7

MMS –VM Interworking

• Objective: Retrieve and Submit Voicemail via MMS (packet) mechanisms, with user behavior as in legacy VM

• Why is this important– VM is delay tolerant, hence should not use real time voice call to

retrieve/submit message

– MMS can use more spectrum efficient 3G high speed radio link

– More optimally scheduled for forwarding to/from a user terminal

– Take advantage of modern devices with large amounts of memory

– Proper QoS treatment at the time of traffic origination

– No transcoding or frame errors yield improved voice quality

– In legacy VM submission/retrieval, the other link is wasted

• Volume of voice mail is large, so these efficiencies amount to considerable operator benefit

• In summary, operator network becomes considerably more efficient by trading delay for throughput, and eliminating idle link

8

Throughput Discussion

• Network performance analysis shows network throughput can increase by allowing longer delay

• There are several compound effects which contribute to this behavior:– Application layer allows composition of message into a large IP

packet, which can be transmitted on a much more efficient high speed bearer

– QoS allows macro-scheduling of IP packets by ordering transmission depending on traffic category (delay intolerant packets first)

– MAC enables micro-scheduling of physical layer packets (frames)

– Physical layer effects include more efficient modulation schemes, which are possible with high speed data (don’t apply to low-bit-rate and delay intolerant voice)

• Rough analysis shows that by migrating voicemail to MMS, the network efficiency can be increased ~ 2.5x for voicemail portion of the traffic, due only to these effects (there are others)

• Fuller advantage can be taken of HRPD and 1X networks

9

Effects of Idle Transmission in VM

• Voicemail retrieval/submission is not a dialogue, hence the other link remains idle while message is being retrieved or submitted– Small exception is prompts by the VM server– However, during prompts reverse link transmits idle frames

• Assume Rate Set 1 link (~8 kbps maximum user payload rate)• Active part of link transmits <100 kbytes in a 100 sec message

– Average rate is lowered due to variable rate vocoder• Assume that inactive part of link can transmit idle frames at 1/8

rate, or approximately 12.5 kbytes– Some full rate frames will be used when transmitting user prompts

• Taking into consideration all these effects, we can conservatively estimate the total effect of idle link transmission to burden the overall throughput by at least 20% penalty– e.g. for a useful payload of 100 kbytes, there will be 120 kbytes

transferred on active and idle links combined• Total combined effect is 2.5x compounded by 1.2x = ~3x

– New packet voicemail can be 3 times as efficient as the legacy VM

10

Estimated Network Impact

• Simplified network impact is illustrated herein

• Assume a medium size city with total 300 BS, each carrying 100 Erlangs of peak hour voice traffic

• Assume voicemail retrieval/submission is 10% of voice traffic

• Total voicemail traffic = 3,000 Erlangs

• Assume VM traffic mix is 50% retrieval, 50% submission

• All VM retrieval can be delivered via MMS (if handsets support it)

• Assume that 50% of submission traffic can be handled via MMS

• Thus 75% of VM traffic, or 2,250 Erl can be migrated to MMS

• Since MMS transmission is ~3x as efficient as circuit-switched VM, the effective savings is ~1,500 Erlangs

• Expressed in the number of required BSs it’s 15, or 5% of the total

11

• This is relatively straightforward to implement– Most interaction is on the server side– Only recipient VM and MMS servers are impacted– QC users do something similar today

– EUDORA manages VM using POP interface in VM server

• May require little standardization

VM Server

MMSServer

VM Arrive

1

3

1A

Forward to MMS

Existing uses (POP)

2

Deposit

VM Retrieval

12

VM Submit with Presence

• When a call attempt is made, the destination presence/availability is first checked

• If not available, the caller is given an option to leave message– May first replay some “presence” cause/prompt

PresenceServer

MMSC

Origination Network

Route

Call Attempt2

76

Presence Status Request

Submit

3

Destination Network

Presence Update(Unavailable)1

t < T0

t = T0

Status (opt. prompt)

4

5

Record

MMSC

Deposit

8

13

VM Submit - Mobile-to-Mobile

MSC

MMSC

Origination Network Route

Call

1

8

7

Redirect on Busy, No Reply, …

Submit

Destination Network

Page, [Alert]

1A

Notify (Caller ID)

5

6

Record

MMSC

Deposit

9

MSC

1

VM Server2

3Signal VM

33A

4

Invoke MMS Submission

5

Listen &Disconnect

Circuit

14

VM Submit - Mobile-to-Land

• If landline device is not a smart phone, VM retrieval must be by traditional means (replaying from VM server)

PSTN/PBXSwitch

MMSC

Origination Network Route

Call1

8

7

Redirect on Busy, No Reply, …

Submit

Destination Network

Alert1A

4

6

Record

VMServer

Replay

10

MSC

1

23Signal VM

33A

Invoke MMS Submission

5

t = T0

t = T1

t > T1

t = T1

Notify

9

Listen &Disconnect

Circuit

15

MMS-VM IW Issues

• One of the issues in MMS-VM Interworking Submission case is the charging model– A detailed solution may involve brief connection to the VM

server, and creation of an accounting record– The submission then is completed via MMS, which will also

generate an accounting record for essentially the same activity from user’s point of view

• Some ways to deal with the issue– It’s in operator’s interest to migrate traffic from voice to

packet data, so an incentive should be provided– This is balanced against the necessary investment to deploy

the feature, though operator is not compelled to do so– Approach 1: Have MMS accounting record generate a credit

flag for the brief voice connection– Approach 2: Do nothing, simply adjust pricing plans based

on tariff analysis of this type of traffic migration– Further input from operators is sought

16

MMS-VM IW Conclusions

• Benefit to operators in standardizing features and deploying VM/MMS server capabilities soon

• Benefit to QUALCOMM to further lowering barriers of entry by virtue of a more efficient network for voice and data

• It would be best to complete work in OMA– The more VM servers are upgraded, the better

– QC pursued in MWG IW Breakout since April 2004

– There was resistance, fate is uncertain without support of operators

• 3GPP2 should be involved– As backup, in case OMA does not produce (efforts blocked)

– For potential supporting network capabilities in Stage 3

– MMS work must continue, 3GPP continues with Release 6, 7…

– 3GPP2 should be leader, not follower

– Eventually, work can roll into OMA if conditions ripe

• QC seeking support of two-pronged approach in OMA/3GPP2

17

Spam Control vs. NFCC, CS

• Spam traffic growth projections

• Spam control architecture

• NFCC architecture

• Strategy in 3GPP2, OMA, IETF

• Bottom line: Spam control can remove many operational headaches as MMS traffic grows

18

Spam Traffic Growth

• Spam is growing not only with total Internet traffic, but as a percentage of e-mail traffic

• Effective spam mitigation requires user control and feedback– Need Stage 2/3 work

– Need interoperable implementations in clients and servers

• Spam control standards solution must be in place soon– Need products before operators are hit with the problem

– If we wait for problem to occur first, it’s too late

– Seeding the network with handsets that support spam control

• In some cases spammers have hit before messaging uptake– Makes messaging useless to customers

• Some GSM operators report problems with unsolicited MMS

19

Spam Traffic Growth

20

Spam Overview

• Spam (unsolicited bulk email) is an ever-growing problem• May include a fraudulent component

– Pretend to be from a legitimate organization– Trick the subscriber into visiting a web site – False belief it is operated by the legitimate organization– Risk of identity theft– Known as “phishing”

• For MMS, spam may arise inherently…– originated within the MMS system, such as via mobiles, VASPs, etc.

• …or from interconnection with other services– such as email.

• Diverse strategies needed for reducing unsolicited and/or fraudulent messaging– Likely to become critical to subscribers' use of and satisfaction with

MMS services

21

Operator-Controlled Filters

• MMSCs need a variety of filtering mechanisms to block traffic from known spam sources

• Such techniques include:– DNS identification and blocking (real-time black-hole services)

of the sending system using the IP address of the sending system

– Maintaining addresses used only for spam reception ("honey-pots"), where such addresses MAY be embedded in web pages, etc. so that spammers will harvest them; when email is received at such an address, it and all identical messages are blocked

• While helpful, these techniques of limited effectiveness• Since these mechanisms do not require subscriber

interaction, and result in the message being blocked or deleted, they will not be further elaborated/standardized– No signaling needed; no Stage 2/3 work

22

Effective Spam Control

• Multiple spam control techniques are needed– no single technique is perfect

• Some techniques can be run in network (MMSC)• Some techniques need subscriber control/feedback

• Operator-Controlled Scoring Rules • Subscriber-Controlled Filters• Subscriber Static Rules• Bayesian Filtering

23

Operator-Controlled Scoring Rules

• Spam score (% likelihood to be spam) is accumulated by each mechanism– Message structure defects likely in spam, unlikely in

legitimate email– Matches to fixed strings within the message content or protocol

fields– Situations in message content or protocol fields, such as long

runs of white space in the message subject– A subject or “from” address which ends in a number– A subject starting with malformed “Re” (e.g, no colon or space

thereafter)– a subject which starts with “Re” in a message which does not

contain an “In-Reply-To” header)– Anomalies in the protocol

24

Spam Score

• The spam score is used in one of the following ways:– Subscriber may configure an automatic-deletion threshold– The spam score included in new-MM notifications– Subscribers may configure MMS client to only fetch

messages whose score is below a dynamic threshold–may alter threshold for each session–depending on mood or circumstance, such as if the

subscriber is roaming, in a hurry, etc.– May allow access to messages which were not

downloaded using a web browser, etc. – the subscriber may then delete, read, or cause to be

downloaded to the mobile

25

Subscriber Static Rules

• Otherwise known as white/black lists

• For maximum effectiveness, need to be customized by subscriber

• Strings to be matched against header fields or body

• Either block (black-list) or permit (white-list) the message

• Such strings may be configured using a web interface…

• …Much easier for subscribers to instead use received messages to update rules– Select one (or more) received messages

– Indicate that all messages which match the To, From, Cc, Subject, or body should be either blocked or accepted.

26

Filter Dialog Example(from Eudora, but shows the point)

27

Bayesian Filtering

• Newer very effective technique

• Maintains two databases– One with sub-strings found in spam messages

– One with sub-strings found in non-spam messages

– Sub-strings include every textual element of a message– Content of headers and body

– Protocol elements, e.g., address headers, trace headers, host names

• Compares all sub-strings of a received message to both databases

• Assigns spam score (0% to 100%)

• May be trated as spam if score exceeds a (user-defined) threshold

• Bayesian filtering proven very accurate if properly “trained”– User indicates if non-spam marked as spam, or spam as non-spam

• Most effective when “training” is done with actual messages

• Adapts to individual subscribers’ preferences, tolerances, etc.– “One man’s spam is another man’s useful information”

28

Spam Notification -- Credit

• Subscriber motivated to correctly identify and notify spam– so that filters are properly trained to improve user’s service

– greater user satisfaction

• When a subscriber indicates that one or more received messages are in fact spam, the MMSC may initiate a billing credit as well as updating either static rules (white/black lists) and/or Bayesian databases

• Provides low-cost, low-hassle means for subscribers to get credit for spam (credit equal to charge for receiving it)

• No incentive for subscriber to lie, since it would cause non-spam to be blocked

29

Anti-Fraud

• MMSCs and/or MMS clients analyze messages for potentially dangerous, misleading, or otherwise suspicious links (“phishing”)

• Help protect user from fraud without blocking legitimate content• Analysis can warn users attempting to follow such links

– Mark the links in an indicative way on display– Input to spam-scoring algorithms

• When MMSC does analysis, include result with message• Examples

– Links which employ an IP address instead of a host name are suspicious because they are often used in malicious ways, but do have legitimate purposes (such as within a local network)

– Link with text containing a host name/link very similar to the actual link– Link contains top level domains that are not at the top level– Link contains encoded characters, whitespace, or other unusual

elements

30

More Details on Examples

• Anchor text is a URL that is different from the href URL– the text http://www.paypal.com linked to

http://www.stealyourinfo.com– Computers generally better at this than humans

• If the text appears to contain a URL as opposed to simple explanatory text (for example, “citibank.com” instead of “click here”), this is especially bad

• URL has internal top-level-domains or white space or encoded characters– http://www.service.paypal.com.to

• URL uses an IP address– http://129.46.50.5/whatever– especially if the address space is not controlled by the operator

31

Spam Control Architecture

32

Spam Control Message Flow

33

NFCC Architecture

• NFCC operates on IP level– Every IP flow arriving to the PDSN is filtered

– IP flow is identified to the subscription (not IP address alone)

– Filter parameters are set on a per-subscription basis

– Content (payload) is not examined, just IP destination/source addresses

• NFCC is located in (or adjacent to) PDSN

• MS contains (retains) filter settings– When MS roams to a different PDSN service area, the new

PDSN settings are updated

34

NFCC vs Spam vs Content Screening

• NFCC and Content Screening have superficial relationship with spam, but they are quite different

• NFCC scope is filtering on layer 2 (IP) and layer 3 (TCP)– This should be contrasted with spam filtering which involves

accepting/rejecting message based on structure, content, etc., i.e., layer 7 (MM4/SMTP/Content)

• Content Screening scope is handset based filtering– One key objective is viruses scanning– In spam effort is distributed between handset and server– Virus scanning is proprietary, while spam control requires

open standards so that handset and server can cooperate, rules can be shared, etc.

– NFCC filter rules can also be controlled by handset, which requires open standards for roaming

– Content screening scope is limited to interface to proprietary screening engine(s) -- not the actual screening

35

Spam Control -- Conclusion

• Spam control can reduce many operational headaches as MMS grows in popularity

• Alignment of 3GPP/PP2/OMA work plans should not put in jeopardy progress of spam control

• As a minimum, the requirements process should start immediately in 3GPP2, while OMA work item is initiated

• Could add Stage 1 and Stage 2 text to current MMS work in 3GPP2 without additional delay