Protocolo Field Test Claro

3E8430LBI - Microsoft
Test Code Test Name Description

TC-BRWSR-ASYNC- Receiving a call while DESCRIPTION:
001a a file is being 1. Go to the test page.
dowloaded 2. Start to download a multimedia file which format is supported by the DuT.
3. Receive a call while the file is being dowloaded.
EXPECTED RESULT:
The call is answered successfully.
The DuT is to keep the download process running in the background.
When the call ends, the DuT must resume wap interface.
If file download finishes before the call, the DuT must never launch the player until
the user hangs up.
TC-BRWSR-ASYNC- Receiving a videocall DESCRIPTION:

002a while a file is being 1. Go to the test page.
dowloaded 2. Start to download a multimedia file which format is supported by the DuT.
3. Receive a videocall while the file is being downloaded.
EXPECTED RESULT:
The videocall is answered successfully. The DuT is to keep the download process
running in the background.
When the videocall ends, the DuT must resume wap interface.
If file download finishes before the videocall, the DuT must never launch the player
until the user hangs up.
ADDITIONAL INFO:
Only if the DuT supports videocall 3G-324M
TC-BRWSR-ASYNC- Receiving a short DESCRIPTION:

003a message while a file 1. Go to the test page.
is being dowloaded 2. Start to download a file which format is supported by the DuT.
3. Receive a SM while the file is being downloaded.
EXPECTED RESULT:
The DuT is to notify the user about the reception of the SM (playing a sound,
displaying the SM notification icon). It may also offer the user the possibility to read
the SM.
Once the SM is read, wap interface is to be resumed.
TC-BRWSR-ASYNC- Receiving a DESCRIPTION:

004a multimedia message 1. Go to the test page.
while a file is being 2. Start to download a file which format is supported by the DuT.
dowloaded 3. Receive a MM notification while the file is being downloaded.
EXPECTED RESULT:
The DuT has to notify the user about the reception of the MM (playing a sound,
displaying the MM notification icon).
TC-BRWSR-ASYNC- Receiving of SMS DESCRIPTION:

006a during an Internet 1. Establish an Internet session on the DuT.
session 2. Send an SM to the DuT.
3. Don't open the SM and remove the notification.
4. Stay in the Internet session for 5 more minutes.
5. End the Internet session and go to the SM inbox.
6. Establish an new Internet session on the DuT.
7. Send again an SM to the DuT.
8. This time open the SM, view the content and exit the SM.
EXPECTED RESULT:
Establish an Internet session on the DuT.
The notification of the SM can be removed.
The DuT reverts back to the Internet session on the same point.
No further SM notifcations are received.
The DuT reverts to the same point of the Internet session before the SM was
received.
Only one SM is received in the inbox.
Establish an new Internet session on the DuT.
The user is notified of the SM.
The DuT reverts to the same point of the Internet session before the SM was
received.
TC-BRWSR-BASOP- Comparing and rating DESCRIPTION:

022a browser performance 1. Open the page www.skysports.com and verify that the page loads within a
reasonable time.
2. View Sky sport banner on the top of the page and observe.
3. Select "More Sport".
4. Select a link from the drop down menu.
5. Select "Buy" and choose any link in the browser categories
EXPECTED RESULT:
Page loads as expected.
Sky news Ticker should scroll along the top.
Drop down menu should appear.
Any link in the drop down menu is displayed and rendered correctly.
Page renders correctly, images of displayed items etc.
TC-BRWSR-BASOP- Browsing and DESCRIPTION:

023a accessing popular 1. Open the browser and access the page www.facebook.com
web pages and that 2. Open the page www.TFL.gov.uk
these render correctly 3. Open the page www.skysports.com
4. Open the page Mail.yahoo.com
5. Open the page www.hotmail.com
6. Open the page www.gmail.com
EXPECTED RESULT:
Page renders correctly and all frames and images are displayed correctly.
Page opens and renders correctly user can navigate at least 3 layers deep.
TC-BRWSR-BASOP- Time to connect to the DESCRIPTION:

024a internet 1. Exit the Browser
2. Access an Internet page from the list with recently viewed pages
3. Repeat this 5 times
EXPECTED RESULT:
The time to connect is consistently under 30 seconds
TC-BRWSR- Compatibility with DESCRIPTION:

EMOCC-001c emoción contents 1. Browse along the contents tree of emoción, Telefónica Móviles WAP site (it should
be taken into account that the emoción contents are modified and enriched
regularly). It is just a general browsing along the main providers in emoción.
EXPECTED RESULT:
The provider contents in emoción should be accessed and displayed correctly.
The DuT configuration will use the WSP or the HTTP stack, depending on the
supported protocol stack.
ADDITIONAL INFO:
For ES:
The next table shows a content tree example of emoción menu, but it's not a
representation of the real contents, because it may change every week. This table
must be updated with the current emoción contents:
It's not necessary to browse the complete emoción tree, just a general browsing and
the access to some important contents.
See bellow the table.
Compatibility with the emoción contents
CONTENT
Novedades
VideoJuegos
Música/Imágenes
Ocio/Chat
Noticias/Tiempo
Deportes
Banca/Compras
Lo+Útil/Correo
Más…
Mi emoción
Buscador
Ir a…
Link to emoción WAP site depends on the country. The proper link can be accessed
by accessing menú option movistar > emoción
For CL:
Access WAP site with both right key and menu option
TC-BRWSR- HTTPS connection DESCRIPTION:

EMOCS-001a 1. If the test is done in Spain, it will be carried out in emoción WAP site
If the test is done in Brazil, it will be carried out in Portal Vivo WAP site
2. If the test is done in Spain, access to emoción-->Banca/Compras-->Bancos--
>Cajas
If the test is done in Brazil, access to Portal Vivo-->Bancos/Finanças-->Ex. Itaú
3. If the test is done in Spain, check that the Bancos and Cajas folders contain
several secure web pages.
If the test is done in Brazil, check that the Bancos/Finanças folder contains
several secure web pages.
4. Verify that the access to these ones will be tested and checked that is correct.
5. Do not type anything.
6. Leave the secure page, browsing an insecure page.
EXPECTED RESULT:
The user should browse correctly and an icon (a padlock) should appear indicating
that the operation is safe.
With 3G DuTs the browsing must be successful with both 2G and 3G bearers.
ADDITIONAL INFO:
In case of 3G DuTs, the browsing through HTTPS contents must be tested with both
the 2G and the 3G bearer.
There are two case:
1.The DuT is capable to display the secure icon (padlock) when browsing a secure
page:
User should browse correctly the page.
DuT must display the secure icon (a closed padlock) when browsing the
secure page.
DuT must delete the icon or present an opened padlock when leaving this
page.
2. The DuT is not capable to display the secure icon (padlock) when browsing a
secure page:
The user should only browse correctly the secure page.
TC-MMSTC-COMPT- Subject field with 40 PRECONDITIONS:

004a Characters Client A
Capability:
Subject with 40 charaters length
Client B
Capability:
Subject with 40 charaters length
MMSC
DESCRIPTION:
The purpose is to verify that a message with 40 chars in the Subject-field is correctly
sent from Client A to Client B via MMSC and that the message is successfully
received and the subject is textually correct.
1. In Client A, create a new MM.
2. In MM header: Add following 40 chars to subject field:
'abcdefghijklmnopqrstuvwxyz0123456789/-+@'.
3. In MM content: In the message text part, enter the text 'Hello World'.
4. In Client A, send MM to Client B.
5. In Client B, receive and open the MM.
6. Verify the pass criteria below.
EXPECTED RESULT:
Client B has received the message and the message is successfully received and the
subject is textually correct.
TC-MMSTC-COMPT- Send and receive PRECONDITIONS:

005a message to multiple Client A
MSISDN MDN and Two Client B
email recipients; To- Three email recipients
Capability:
Valid email address in US-ASCII format
MMSC
DESCRIPTION:
The purpose is to verify that messages can be simultaneously and correctly sent
from Client A to multiple MSISDN/MDN clients and multiple email recipients via
MMSC and that the message is successfully received by all the recipients listed in
the 'To:'-field.
2. In MM header: To-field is set to two clients (using MSISDN/MDN numbering) and
three email recipients.
4. In Client A, send MM to multiple MSISDN/MDN clients and multiple email
recipients via MMSC.
5. In multiple MSISDN/MDN clients and multiple email recipients via MMSC, receive
and open the MM.
EXPECTED RESULT:
All MSISDN/MDN clients and all email recipients listed in the 'To:'-field have received
the message successfully. .
TC-MMSTC-COMPT- Send and receive PRECONDITIONS:

006a message to multiple Client A
MSISDN MDN and Two Client B
email recipients; Cc- Three email recipients
Capability:
Valid email address in US-ASCII format
MMSC
DESCRIPTION:
The purpose is to verify that messages can be simultaneously and correctly sent
from Client A to multiple MSISDN/MDN clients and multiple email recipients via
MMSC and that the message is successfully received by all the recipients listed in
the 'Cc:'-field.
2. In MM header: Cc-field is set to two clients (using MSISDN/MDN numbering) and
three email recipients.
4. In Client A, send MM to multiple MSISDN/MDN clients and multiple email
recipients via MMSC.
5. In multiple MSISDN/MDN clients and multiple email recipients via MMSC, receive
and open the MM.
EXPECTED RESULT:
All MSISDN/MDN clients and all email recipients listed in the 'Cc:'-field have received
the message successfully. .
TC-MMSTC-COMPT- Recipient name PRECONDITIONS:

009a Client A
DESCRIPTION:
The device must confirm whether the sender's and/or recipient's address
(independently of the format used: E.164 or [RFC 0822] is registered in the handset
or SIM/USIM address book, and if so, it must substitute the sender's address with the
name registered in the address book.
1. In client A, create a new MM.
2. In MM header: To-field is set to any legal address, MSISDN from SIM/USIM or
phonebook
3. In MM content: Add any content
EXPECTED RESULT:
The recipient's name associated with that number shall appear in the terminal.
TC-MMSTC-COMPT- Message with text, PRECONDITIONS:

010b audio and images. Client A
DESCRIPTION:
The body of the MMS message could contain text, images, audio, video files.
It shall be possible for such contents to be stored in a local folder (e.g. multimedia
album) or taken with audio recording or camera functionality (video, image, etc..)
while composing the MMS.
1. In client A, create a new MM
2. In MM header: set a legal address
3. In MM content: set text, image and sound files.
4. Verify the pass criteria below
EXPECTED RESULT:
In client A, check that body of MM contain text, image and sound files.
ADDITIONAL INFO:
For MX, GT, SV, NI, PA:
Compose MMI with following combinations and send it:
Text / MIDI / JPEG
Text / AMR / JPEG
Text / MP3 / JPEG
Text / MIDI / GIF
Text / AMR / GIF
Text / MP3/ GIF
TC-MMSTC-COMPT- Supported slides in a PRECONDITIONS:

011a MM Client A
DESCRIPTION:
Messages may be formed by several slides. The number of supported slides in a MM
shall be at least four.
1. In client A, create a new MM with several slides temporarily synchronized.
Minimum number of slides is 4.
2. In MM header: set a legal address
3. In MM content: any content
EXPECTED RESULT:
The messages will possibly contain several pages temporarily synchronized.
TC-MMSTC-COMPT- USIM addresses PRECONDITIONS:

015a Client A
DESCRIPTION:
The address book of SIM/USIM shall be used to select addressees. This address
book will store:
·E.164 formats and short numeration (SIM).
·E.164 formats, short numeration and RFC0822 formats (USIM).
1. In client A, create a new MM.
2. In MM header: set a legal address. The phonebook of SIM/USIM will be used to
select the addressees.
3. In MM content: any content
EXPECTED RESULT:
In client A, It must be checked through the MMS menu that the terminal allows to the
user choosing any register stored in the handset's SIM phonebook. In case of the
USIM allows adding the complementary registers like the second name and the e-
mail address.
TC-MMSTC-MMITC- Deleting of an MM PRECONDITIONS:

018a from Inbox Some MMS in DuT's Inbox.
DESCRIPTION:
1. Delete one MM from DuT's Inbox.
EXPECTED RESULT:
The MMS deleted it is not in DuT's Inbox.
TC-MMSTC-MMITC- Deleting of all MMs in PRECONDITIONS:

019a Inbox Some MMS in DuT's Inbox
DESCRIPTION:
1. Delete all the MMS in DuT's Inbox.
EXPECTED RESULT:
There are not any MMS in DuT's Inbox.
TC-MMSTC-MMITC- Deleting of all MMs in PRECONDITIONS:

020a Sentbox Some MMS in DuT's Sentbox.
DESCRIPTION:
1. Delete all the MMs in DuT's Sentbox.
EXPECTED RESULT:
There are not any MMS in DuT's Sentbox.
TC-MMSTC-RECVN- Reception of audio DESCRIPTION:

010b messages 1. Send to the DuT a MM with a midi sound file.
2. It must be correctly received.
3. The midi file should be reproducible
EXPECTED RESULT:
The MM should be propperly retrieved and the midi file should be reproducible.
ADDITIONAL INFO:
For MX:
Add also text.
Repeat procedure for AMR, MP3 and other supported audio formats.
TC-MMSTC-RECVN- Behaviors upon PRECONDITIONS:

012a receiving a Client A
notification. DESCRIPTION:
The device shall support the following behaviors upon receiving a notification:
*Automatic retrieval description for GPRS device class A

1) Established voice call: automatic retrieval with no action required by user..
2) Established data session: automatic retrieval with no action required by user.
*Automatic retrieval description for GPRS device class B

1) Established voice call: automatic message retrieval as soon as the voice call is
being terminated.
*Automatic retrieval description for GPRS device class C : Automatic retrieval with no
action required by the user (SMS via GPRS MUST be supported).
*Automatic retrieval description for UMTS device

1) Established voice call: automatic retrieval with no action required by user.
*Manual retrieval for UMTS terminal and for GPRS devices (class A, class B and
class C)
1) In case that the user confirms the retrieval of the MM, the device will use the
retrieval mechanisms explained in the previous sections to manage retrieval of the
MM.
2) In case that the user postpones retrieval of a message (by non-confirmation of
the retrieval), the notification will appear in the MMS inbox folder. When the user
selects the corresponding notification the process of downloading the MM will start,
as described above.
* Recommended Retrieval Mode M In case that the MMS Notification recommends

the manual retrieval then the message will only be retrieved after user confirmation,
regardless of the device configured retrieval mode. (MMS conformance Document
1.3)
The following steps will be carried out for class A and B:

1. Establish a voice call. Receive a MM.
2. Establish a data session. If the terminal is not able to manage two or more active
PDP contexts and/or several simultaneous WAP sessions.
3. Establish a data session. If the terminal is able to manage two or more active PDP
contexts and/or several simultaneous WAP sessions.
The following steps will be carried out only to terminals supporting SMS over GPRS,
class C:
1. Establish a data session. If the terminal is not able to manage two or more active
PDP contexts and/or several simultaneous WAP sessions.
TC-MMSTC-RECVN- MMS during voice call PRECONDITIONS:

016a Client A
Client B
DESCRIPTION:
Receive MM while in call.
1. In Client A, establish a voice call and maintain the call .
2. In Client B, compose a MMS and send it to Client A.
3. In Client A, verify the successful reception of the MMS while in call (in 3G mode) or
verify the reception of a MM notification (in 2G mode).
4. Verify the pass criteria.
EXPECTED RESULT:
Receive the MM without errors if in 3G mode
Receive a MM notification immediately after the call has been terminated
Download the MM automatically or upon user request
TC-MMSTC-RECVN- Reception of an MM DESCRIPTION:

023a with a 3GPP video file 1. Send to the DuT a MM with a 3GPP video file + text.
+ text. 2. It must be correctly received.
3. The 3GPP file should be reproducible.
4. Save the 3GPP file in the phone's memory.
EXPECTED RESULT:
The MM should be properly retrieved and the 3GPP file should be reproducible, and
text must be readable. It must be possible to save the 3GPP file in DuT's memory.

024a with an MP3 file + 1. Send to the DuT a MM with an MP3 sound file + text.
text. 2. It must be correctly received.
3. The MP3 file should be reproducible
4. Save the MP3 file in the phone's memory.
EXPECTED RESULT:
The MM should be properly retrieved and the mp3 file should be reproducible, and
text must be readable. It must be possible to save the mp3 file in DuT's memory.

025a with an AMR file + 1. Send to the DuT a MM with an AMR sound file + text.
text. 2. It must be correctly received.
3. The AMR file should be reproducible
4. Save the AMR file in the phone's memory.
EXPECTED RESULT:
The MM should be properly retrieved and the AMR file should be reproducible, and
text must be readable. It must be possible to save the AMR file in DuT's memory.

026a with a MIDI file + text. 1. Send to the DuT a MM with a MIDI sound file + text.
2. It must be correctly received.
3. The MIDI file should be reproducible
4. Save the MIDI file in the phone's memory.
EXPECTED RESULT:
The MM should be properly retrieved and the MIDI file should be reproducible, and
text must be readable. It must be possible to save the MIDI file in DuT's memory.

028a with a MPEG4 video 1. Send to the DuT a MM with a MPEG4 video file + text.
file + text. 2. It must be correctly received.
3. The MPEG4 file should be reproducible.
4. Save the MPEG4 file in the phone's memory.
EXPECTED RESULT:
The MM should be properly retrieved and the MPEG4 file should be reproducible,
and text must be readable. It must be possible to save the MPEG4 file in DuT's
memory.
TC-MMSTC-SENDG- Sending Attachment PRECONDITIONS:

006a in Empty message- Client A
vCard Capability:
vCard 2.1 MIP
DESCRIPTION:
The purpose is to verify that a vCard MIP object is correctly sent from Client A.
Verification is done by sending the message from Client A to a test tool, which will
verify that the Content type is correct and that the vCard file is included in the MM
sent by Client A.
1. In Client A, create a new Address Book entry containing all possible fields of the
reference content 'John Doe.vcf' as supported by the MMI of Client A
2. In Client A, create a new MM using the vCard object from the above mentioned
address book entry.
3. In MM header: To-field is set to any legal address.
4. In Client A, send MM to the Test Tool.
5. In the Test Tool, accept the message .
EXPECTED RESULT:
Test Tool has received the message with vCard object and the message PDU content
type is set to application/vnd.wap.multipart.related or
application/vnd.wap.multipart.mixed.
The MM message content shall contain a part with content type set to text/xvCard. If
ixit mms version equals '1.3' the text/x-vCard part shall contain, at least, the following
vCard properties:
N (Name), which shall be textually correct
VERSION, which shall be set to '2.1'
Three EMAIL property fields which shall be textually correct
Three TEL property fields which shall be textually correct.
TC-MMSTC-SENDG- Text with US-ASCII PRECONDITIONS:

009a encoding Client A
Supports ASCII encoding when creating messages
Client B
DESCRIPTION:
The purpose is to verify that a text object with US-ASCII encoding is correctly sent
from Client A to Client B and that the received message is textually correct.
2. In MM header: To-field is set to Client B.
3. In MM content: In the message body, enter text as in file Text_us-ascii.txt.
EXPECTED RESULT:
Client B has received the message and the received message is textually correct.
TC-MMSTC-SENDG- Text with special PRECONDITIONS:

010a characters Client A
Supports utf-8 encoding when creating messages
Client B
DESCRIPTION:
The purpose is to verify that a text object with UTF-8 encoding is correctly sent from
Client A to Client B and that the received message is textually correct.
2. In MM header: To-field is set to Client B.
3. In MM content: In the message body, enter text as in file Text_UTF-8.txt.
(Alternative characters may be substituted where necessary as described in the
reference content document)
EXPECTED RESULT:
Client B has received the message and the received message is textually correct.
TC-MMSTC-SENDG- Sending a MM to an DESCRIPTION:

013b electronic mail This test consists on sending a MM (image, audio, text and video) to an electronic
account mail account: (Lotus, Outlook or of Internet).
1. Send a MM to an electronic mail account.
2. Verify that it correctly shows the MM format: name.ext. In case the object doesn't
show its extension, it will not be able to be extracted or stored in local because it will
detect it as an unknown file.
3. The content of the MM that the electronic mail customer receives, shall never
come embedded in the mail but as an added object.
EXPECTED RESULT:
The message should be retrieved propperly
ADDITIONAL INFO:
For GT, SV, NI, PA:
Send MM with following contents:
Picture / Text
Audio / Text
Video / Text
Multicontent
TC-MMSTC-SENDG- Indicator of sending DESCRIPTION:

021a progress 1. Send a MM.
2. Start a voice call while sending the message.
1. Check that during the dispatch a progress indicator appears on screen.
2. Check that during the call, the GPRS communication stops and the re-establishes
after finalizing the voice call, and that the message reaches its destination.
EXPECTED RESULT:
During the call, the GPRS communication should stop and re-establish after finalizing
the voice call, the message reaches its destination.
TC-MMSTC-FEATR- VIDEO H263 + AMR- PRECONDITIONS:

025a NB.3gp Client A
DESCRIPTION:
1. Send a MM video with the following characteristics:
100 K
DuT Supported resolution
Video: H263 94 Kb 176x144 H263
Bitrate: 67 Kbps
Audio: Amr
Bitrate: 12.2 Kbps
Frequency: 8000 Khz
Channels: Mono
EXPECTED RESULT:
Receive a MM with the sound perfectly adapted to the terminal's characteristics.
TC-SMSTC-CODTC- Terminated DESCRIPTION:

001a Concatenated SM - 1. Using the MMI procedures defined by the manufacturer, switch display language
UCS2 alphabet (max. to UCS2 (e.g. Hebrew).
capacity) 2. Create and send an SMS message of 160 characters (in Default 7 bit alphabet) to
the DuT.
3. Check that it is correctly received at the DuT.
EXPECTED RESULT:
Only one message is correctly received at the DuT.
TC-SMSTC-CODTC- Input concatenated DESCRIPTION:

002a SM - UCS-2 alphabet 1. Using the MMI procedures defined by the manufacturer, create and send
(over 70 characters) concatenated SMS messages supporting the text (longer than 70 UCS-2 characters
and max. capacity).
2. Check the display if the number of sent messages is indicated and correct.
3. Check that the SMS are correctly received at their destination, and that the entire
text (longer than 70 UCS-2 characters and max. capacity) can be read without
missing characters or redundancy.
EXPECTED RESULT:
The MS indicates correctly how many messages are sent. The messages are
correctly received at its destination and the entire text can be read without missing
characters or redundancy.
ADDITIONAL INFO:
The message will contain UCS-2 characters.
TC-SMSTC-MMITC- Terminated DESCRIPTION:

003b Concatenated SM - 1. Make sure of the maximum number of concatenated SMS that supports the DuT.
Default 7-bit alphabet 2. Arrange for a concatenated SM that contains max. capacity of default 7 bit
(max. capacity) alphabet content to be sent to the DuT.
Check that:
a. Entire text can be read without missing characters or redundancy. All message
content are correctly displayed. Check especially the reassembly points.
b. All content is displayed in one message.
EXPECTED RESULT:
The entire text can be read in the DuT without missing characters or redundancy. All
message content are correctly displayed. And all content is displayed in 1 message.
ADDITIONAL INFO:
Include capital letters, simbols & accents
TC-SMSTC-MMITC- Substitution of sender DESCRIPTION:

004b number 1. Check that a SMS message can be sent to the DuT from a device registered in
DuT phonebook (SIM/USIM or phone memory).
2. Send SMS from registered device to DuT.
3. Once the SMS is received in the DuT, check that the sender's name registered in
the phonebook is displayed instead of its number.
EXPECTED RESULT:
Upon receipt of a message, the device shall check whether the sender’s number is
registered in the SIM/USIM or in handset phonebook. If a match is made, the name
shall be displayed rather then the number.
ADDITIONAL INFO:
Verify that name is displayed instead of number also in messages stored in "Sent"
folder
TC-SMSTC-RCPTC- Message class 0 to 3 DESCRIPTION:

001a (SMS mobile 1. Arrange for a Class 0 SM to be sent to the MS.
terminated) - SM 2. By means of the MMI commands in the MS, display the SM and ensure that it has
class 0 (accept and been correctly received.
displayed, but not 3. Turn the MS off and on again, and check that the SM is not in the message
stored) storage memory.
EXPECTED RESULT:
The SM is received but not stored, and not available after the MS is switched off and
on again.
TC-SMSTC-RCPTC- Reception of SM DESCRIPTION:

003a class 0 during a voice 1. Establish a voice between DuT and another device.
call 2. Arrange for a Class 0 SM to be sent to the DuT.
3. Check that the messages is properly received and pops up on the display
4. Terminate the voice call
5. Verify that the message is not saved in the message inbox
EXPECTED RESULT:
The DuT must receive the Class 0 message while engaged in a voice call

004b (SMS mobile 1. Arrange for a Class 1 SM to be sent to the MS.
class 1 (storing in ME been correctly received.
and displaying) 3. Turn the MS off, and replace the SIM.
4. Turn on the MS and check that the SM is still in the mobile message storage
memory.
5. Place the original SIM in another MS and ensure that the message is not in the
message storage memory on the new MS.
EXPECTED RESULT:
The SMS is received and stored in the MS.
If it is not possible, it will be stored in the SIM.
ADDITIONAL INFO:
160 characters, include capital letters, simbols & accents

005b (SMS mobile 1. Arrange for a Class 2 SM to be sent to the MS.
class 2 (storing in SIM been correctly received.
and displaying) 3. Turn the MS off, and replace the SIM.
4. Turn on the MS and check that the SM is not in the message store.
5. Place the original SIM in another MS and ensure that the message is in the
message store on the new MS.
EXPECTED RESULT:
The SMS is received and stored in the SIM.
ADDITIONAL INFO:
160 characters, include capital letters, simbols & accents
TC-SMSTC-RCPTC- Reception of SM DESCRIPTION:

006a class 3 1. Arrange for a Class 3 SM to be sent to the MS.
2. By means of the MMI commands in the TE, display the SM in the TE and ensure
that it has been correctly received.
3. Then check the MS and ensure that the SM has not been placed in the message
storage memories of the DuT or of the SIM.
EXPECTED RESULT:
The SM is not placed in the message storage memories of the MS or of the SIM, but
is passed directly to the TE.
TC-SMSTC-RCPTC- Reception of SM type DESCRIPTION:

007a 0 class 0 1. Arrange for a type 0 SMS class 0 message to be sent to the DuT.
2. Check that the successful reception of the message is acknowledged to the
network.
3. Check that the DuT does not indicate the receipt of this message to the user and
that the message is not stored in the SIM or ME.
EXPECTED RESULT:
The message content shall be discarded but the successful reception of the type 0
SM is acknowledged to the network.
Type 0 SMS need to be sent from a specific tool.
TC-SMSTC-RCPTC- Reception of SM type DESCRIPTION:

008a 0 class 2 1. Arrange for a type 0 SMS class 2 message to be sent to the DuT.
2. Check that the successful reception of the message is acknowledged to the
network.
3. Check that the DuT does not indicate the receipt of this message to the user and
that the message is not stored in the SIM or ME.
EXPECTED RESULT:
The message content shall be discarded but the successful reception of the type 0
SM is acknowledged to the network.
Type 0 SMS need to be sent from a specific tool.
TC-SMSTC-RCPTC- SMS mobile DESCRIPTION:

013a originated - Status 1. Using MMI commands, set the Status Report in the MS.
Report 2. Send an MO SM with the Status Report parameter included.
3. Check that the message reaches its destination, and that the Status report is
returned by the network and correctly received by the MS.
EXPECTED RESULT:
The message reaches its destination, and the Status report is returned by the
network and correctly received by the MS.
TC-SMSTC-SNDTC- Input SM (160 DESCRIPTION:

001b characters) when 1. Using the MMI procedures defined by the manufacturer create an SMS of 160
using MMI language characters.
of UCS2 alphabet and 2. Write the message using one predictive text algorithm (e.g. Itap, T9, Zi etc) using a
message content is display language that has accented characters UCS2 (e.g. Spanish).
default 7-bit alphabet 3. Send the SMS message of 160 characters including characters containing accents
(UCS-2 characters).
4. Check that only one message is sent, as the SM is coded in Default 7-bit alphabet
(and not UCS2 Alphabet).
EXPECTED RESULT:
The message is correctly received at its destination as one single message (not a
concatenated message), with the accented characters converted to non-accented
characters except for the accented 'e' (é), i.e., the message is received in Default 7
bit alphabet.
ADDITIONAL INFO:
For CL:
Include accents and letter Ñ
TC-SMSTC-SNDTC- Minimum number of DESCRIPTION:

008a SM 1. Edit a message formed by 6 concatenated SM.
2. Send the concatenated message.
3. Verify that the message is properly sent.
EXPECTED RESULT:
Verify that the 6 concatenated SM message is properly sent
TC-USBLT-RGSTT- Sending a SM to a DESCRIPTION:

001a wrong number 1. Send a SM to a wrong number.
2. Confirm that the SM cannot be sent.
3. Check the Message Menu Options.
4. Verify that the SM has not been sent.
EXPECTED RESULT:
The SM shall be stored as a unsent SM.
TC-GSMFT-BASOP- Mobile originated call DESCRIPTION:

002a to occupied phone 1. Perforn an outgoing voice call from DuT to a busy fixed network number not
having Call Waiting service activated.
2. Check that the mobile correctly indicates the busy status of the distant party,
emiting the 'engaged' tone (unless the other telephone supports the call waiting
function).
EXPECTED RESULT:
The DuT must be informed that the distant party is busy.
TC-GSMFT-BASOP- Mobile originated DESCRIPTION:

004a international call 1. Enter an international telephone number using the “+” key and the destination
country code.
2. Confirm that communication is established.
3. The international call must be established.
EXPECTED RESULT:
Voice call to international correctly established.
TC-GSMFT-BASOP- Finishing of a call by a DESCRIPTION:

005b fixed network The MS shall make an outgoing voice call to a PSTN number.
telephone 1. Make a voice call to a PSTN number. Ensure that the call completes.
2. Check that Call Waiting Notification, COLP and SS notification (such as "call is
forwarded") is correctly displayed and does not disturb the call setup.
3. Check that alerting tone is audible at the MS and that voice connection in both
directions is established.
EXPECTED RESULT:
The MS completes each call correctly, COLP, Call Waiting and SS notification
information is correctly displayed, alerting indication is audible, and a voice
connection in both directions is established.
ADDITIONAL INFO:
Repeat the procedure for a fixed network number:
- stored in SIM card
- stored Terminal
- not stored
Call is finished by fixed network phone
TC-GSMFT-BASOP- Voice Ciphering DESCRIPTION:

008a 1. Check what type the voice ciphering algorithms are active in the network.
2. Establish a voice call and get a log file.
3. The DuT must keep a voice call with an algorithm supported by itself and the
network.
4. If the DuT doesn't support the NW ciphering it must keep the voice call without
ciphering (A5/0).
Note: this test needs log software in order to check the ciphering algorithms used by
the DuT.
EXPECTED RESULT:
DuT uses ciphering according to network
TC-GSMFT-BASOP- Voice mail DESCRIPTION:

010a 1. Check if the voicemail account has been created for the MSISDN. Case it doesn’t
exist, create a voicemail account (Call to *555)
2. Leave 5 voice messages in the voicemail account of the terminal.
3. The terminal must display a notification of new voicemail message recorded (ex.
Icon).
4. Access the voicemail account and listen to 5 voice messages recorded, deleting
them one by one.
EXPECTED RESULT:
All the messges must be properly listened and the notification icon must be shown.
After listening to the voicemail messages and deleting them, the terminal must delete
the voicemail message notification (icon).
TC-GSMFT-CLIRT- CLIR Test DESCRIPTION:

001a 1. Dial *#31# (Interrogation), and ensure that the phone correctly indicates the CLIR
status as not active.
2. Use ME1 to call ME2. Dial #31# before ME2 number.
3. Check that the ME1 number is shown as "unknow" on ME2.
4. Repeat the same procedure but using the ME1 menu instead the code for
changing CLIR status.
5. Check that the ME1 number is shown as "unknown" on ME2.
EXPECTED RESULT:
Check that the ME1 number is shown as "unknown" on ME2 using both procedures,
code and menu.
TC-GSMFT-CLIRT- CLIR Test - reception PRECONDITIONS:

002a Reference ME with CLIR activated.
DESCRIPTION:
1. Establish an MT voice call from the reference ME with CLIR activated.
2. Check the behaviour of the DuT.
EXPECTED RESULT:
The calling number should not be shown as the calling ME has CLIR activated. A
message such as 'Hidden number' must be shown instead.
The DuT should be able to receive, answer and maintain the call without problem.
TC-GSMFT-SUPPL- Barring all outgoing DESCRIPTION:

007b calls Ensure that call barring can be properly activated.
1. Dial the code string for BAOC *33*PW# (where PW is the current password) and
check that the DuT displays a response indicating that the service has been
activated. Check also that the service has been activated by attempting to make an
outgoing call to a barred number.
2. Repeat procedure 1, but using menu commands instead.
EXPECTED RESULT:
The MS displays a response indicating that the service has been activated, and
indicates that a call to a barred number is in fact barred.
ADDITIONAL INFO:
For CL:
Verify that emergency calls are not barred and that an emergency call can be
established
TC-GSMFT-SUPPL- Barring outgoing DESCRIPTION:

008a international calls Ensure that call barring can be properly activated.
1. Dial the code string for BOIC *331*PW# (where PW is the current password) and
check that the mobile displays a response indicating that the service has been
EXPECTED RESULT:
TC-GSMFT-SUPPL- Barring all outgoing PRECONDITIONS:

009a international calls, To do this test a foreign operator SIM card of a foreign operator must be used with
except calls to the call restriction service activated.
HPLMN DESCRIPTION:
Ensure that call barring can be properly activated.
1. Dial the code string for BOIC-exHC *332*PW# (where PW is the current password)
and check that the mobile displays a response indicating that the service has been
EXPECTED RESULT:
TC-GSMFT-SUPPL- Barring incoming calls DESCRIPTION:

010a Ensure that call barring can be properly activated.
1. Dial the code string for BAIC *35*PW# (where PW is the current password) and
check that the mobile displays a response indicating that the service has been
activated. Check that the service has been activated by attempting to make an
incoming call from a barred number.
EXPECTED RESULT:
TC-GSMFT-SUPPL- Barring incoming calls PRECONDITIONS:

011a when roaming To do this test a foreign operator SIM card of a foreign operator must be used with
the call restriction service activated.
DESCRIPTION:
Ensure that call barring can be properly activated.
1. Dial the code string for BAIC-R *351*PW# (where PW is the current password)
activated. Check that the service has been activated by attempting to make an
incoming call from a barred number.
EXPECTED RESULT:
TC-GSMFT-SUPPL- Call barring password PRECONDITIONS:

012a change MS in idle state, call barring password configured
DESCRIPTION:
1. Dial the code string *03**OLD* NEW*NEW# (where OLD is the old password and
NEW is the new password) and check that the mobile displays a response indicating
that the password has been changed.
2. Dial the code string **03**OLD*NEW*NEW# (where OLD is the old password and
NEW is the new password) and check that the mobile displays a response indicating
that the password has been changed.
3. Dial the code string *03*330*OLD*NEW*NEW# (where OLD is the old password
and NEW is the new password) and check that the mobile displays a response
indicating that the password has been changed.
4. Change the password using menu commands and check that the mobile displays
a response indicating that the password has been changed.
EXPECTED RESULT:
The MS displays a response indicating that the password has been changed.
TC-GSMFT-SUPPL- CFU (Call Forwarding DESCRIPTION:

003b Unconditional 1. Dial the code string (CFU) with a number phone to which calls shall be forwarded,
registered. Check also that the service has been registered by performing an
interrogation by code string.
2. Make calls from any terminal to the DuT. The calls should be forwarded to the
indicated number.
3. Deactive unconditional forwarding by code string and make calls to check it. The
DuT must receive the calls.
4. Repeat procedure 1 to 3, but using menu commands instead.
EXPECTED RESULT:
1.The DuT registers the supplementary service and displays the fact correctly.
2. Activation:The calls should be forwarded to the indicated number.
3. Deactivation: The DuT must receive the calls
The results obtained by the two procedures shall be identical.
ADDITIONAL INFO:
CFU: Code **21*DN# (Activation of unconditional forwarding)
Code #21# (Deactivation of unconditional forwarding)
Code *#21# (Status)
Repeat procedure for:
- fixed network number
- mobile number
For MX:
- voice mail 186 or +52551255000
For GT:
- voice mail *86 or +50254040000
For SV:
- voice mail *86 or +50377019995
For NI:
- voice mail *86 or +5058101005
For PA:
- voice mail *86 or +50766101000
For GT, SV, NI, PA:
Check that "all calls forwarded" flag appears in idle screen when CFU activated, and
check that flag disappears when CFU is deactivated.
TC-GSMFT-SUPPL- CFB (Call Forwarding DESCRIPTION:

004b on Mobile Subscriber 1. Dial the code string (CFBy) with a number phone to which calls shall be call
Busy) forwarding when busy, and check that the mobile displays a response indicating that
the service has been registered. Check also that the service has been registered by
performing an interrogation by code string.
2. Make a call from the DuT to a support terminal.
3. While the DuT is busy, make a call from any terminal to it. The call should be
forwarded to the indicated number in the code string.
4. Deactive forward when busy by code string and repeat the procedure 2 and 3, but
now the call should no longer be forwarded.
EXPECTED RESULT:
1. The MS registers the supplementary service and displays the fact correctly.
2. Activation:The call must be forwarded when busy to the indicated number.
3. Deactivation: The call must be forwarded to the voice mail.
For this test the "call waiting" must be disable.
ADDITIONAL INFO:
CFBy: Code **67*DN# (Activation of forward when busy)
Code #67# (Deactivation of forward when busy)
Code *#67# (Status)
- mobile number
For MX:
- voice mail 186 or +52551255000
For GT:
- voice mail *86 or +50254040000
For SV:
- voice mail *86 or +50377019995
For NI:
- voice mail *86 or +5058101005
For PA:
- voice mail *86 or +50766101000
TC-GSMFT-SUPPL- CFNRy (Call DESCRIPTION:

005b Forwarding on No 1. Dial the code string (CFNRy) with a number phone to which calls shall be call
Reply) forwarding if no answer, and check that the mobile displays a response indicating
that the service has been registered. Check also that the service has been registered
by performing an interrogation.
2. Make a call from any terminal to the DuT, but don't answer the call. The call should
be forwarded to the indicated number.
3. Deactive forward if no answer by code string and repeat the procedure 2 , but now
the call should no longer be forwarded.
EXPECTED RESULT:
1.The MS registers the supplementary service and displays the fact correctly.
2. Activation: The call must be forwarded if no answer to the indicated number.
3. Deactivation: The call should no longer be forwarded.
ADDITIONAL INFO:
CFNRy: Code **61*DN# (Activation of forward if no answer)
Code #61# (Deactivation of forward if no answer)
Code *#61# (Status)
- mobile number
For MX:
- voice mail 186 or +52551255000
For GT:
- voice mail *86 or +50254040000
For SV:
- voice mail *86 or +50377019995
For NI:
- voice mail *86 or +5058101005
For PA:
- voice mail *86 or +50766101000
TC-GSMFT-SUPPL- CFNRc (Call DESCRIPTION:

006b Forwarding on Mobile 1. Dial the code string (CFNRc) with a number phone to which calls shall be call
Subscriber Not forwarding when phone off or no coverage, and check that the mobile displays a
Reachable) response indicating that the service has been registered. Check also that the service
has been registered by performing an interrogation by code string.
2. Turn the DuT off or put in a no coverage area.
3. Make calls from any terminal to the DuT. The calls must be forwarded to the
indicated number.
4. Deactive call forwarding when phone off or no coverage and repeat procedure 2
and 3. The call should no longer be forwarded.
EXPECTED RESULT:
1. The MS registers the supplementary service and displays the fact correctly.
2. Activation: The calls must be forwarded when phone off or no coverage to the
indicated number.
3. Deactivation: The calls should no longer be forwarded.
ADDITIONAL INFO:
CFNRc: Code **62*DN# (Activation of forward when phone off or no coverage).
Code #62# (Deactivation of forward when phone off or no coverage).
Code *#62# (Status)
- mobile number
For MX:
- voice mail 186 or +52551255000
For GT:
- voice mail *86 or +50254040000
For SV:
- voice mail *86 or +50377019995
For NI:
- voice mail *86 or +5058101005
For PA:
- voice mail *86 or +50766101000
TC-GSMFT-SUPPL- Call forwarding when PRECONDITIONS:

018a DuT is busy and call 1. Call waiting is activated in DuT.
waiting is activated. 2. In DuT, enable call forwarding when busy with menu option, and check that the
mobile displays a response indicating that the service has been registered. Check
also that the service has been registered by performing an interrogation by means of
menu option.
DESCRIPTION:
1. Make a call from the DuT to a support terminal.
2. While the DuT is busy, make a call from any terminal to it. Ensure that call waiting
indication (appropriate tone and display) occurs.
3. Reject the second incoming call and verify that is forwarded to the indicated
number in the code string.
EXPECTED RESULT:
The DuT registers the supplementary service and displays the fact correctly.
Receiving the second call, call waiting indication (appropriate tone and display) must
occur.
The second incoming call must be forwarded when it is rejected to the indicated
number.
TC-GSMFT-SUPPL- Call Hold DESCRIPTION:

002a Ms with an active call in progress.
1. Using code 2SEND, place the call on hold, and then retrieve the call using code
1SEND. Check that the distant party heard the call go on hold.
2. Using code DNSEND (where DN s the number called), place the call on hold and
make a second call. Using code 2SEND place the active call on hold and retrieve the
held call. Ensure that conversation is possible on the new call.
3. Repeat procedures 1 & 2 using menu commands.
4. Check that if the party on hold releases the call, the MS indicates that the call has
ended.
5. Check that is the distant party releases the call during the attempt to retrieve it, the
MS indicates that the call has ended.
6. Check that if distant party releases the active call, the held call can still be
retrieved.
EXPECTED RESULT:
1. The distant party hears the call go on hold.
2. The two calls are alternated and conversation is possible on the new call.
3. As for 1 & 2.
4. The MS indicates that the call has ended.
5. The MS indicates that the call has ended.
6. The held call can still be retrieved.
TC-GSMFT-SUPPL- Call Waiting. Normal DESCRIPTION:

001c operation, waiting call 1. Arrange for an incoming call to be received. Ensure that call waiting indication
indication (appropriate tone and display) occurs. Clear the existing call and ensure that the
phone alerts after the first call was cleared, and that the waiting call can be accepted.
2. Arrange for an incoming call to be received. Ensure that call waiting indication
(appropriate tone and display) occurs. Place the existing call on hold and ensure that
the waiting call can be accepted.
3. Arrange for an incoming call to be received. Ensure that call waiting indication
(appropriate tone and display) occurs. Have the distant party clear the existing call
and ensure that the waiting call can be accepted.
EXPECTED RESULT:
The DuT provides an appropriate tone and display, and allows the waiting call to be
accepted.
ADDITIONAL INFO:
For MX, GT, SV, NI, PA, CL:
Activate call wating with short codes and MMI.
Activate: *43#
Deactivate call wating with short codes and MMI and verify locution that telephone is
busy.
Deactivate: #43#
TC-GSMFT-SUPPL- MultiParty call DESCRIPTION:

013b handling 1. Dial the code 3 SEND to join the calls. Check that all three parties can speak to
each other
2. After completing procedure 1, arrange for a further incoming call to be made.
Check that the call is indicated, and then answer it, placing the multiparty call on hold
(code 2 SEND). Check that conversation is possible on the new call.
3. After completing procedure 2, dial the code 3 SEND to join the calls. Check that all
four parties can speak to each other.
4. After completing procedure 3, place the multiparty call on hold, and make a new
outgoing call (DN SEND). Check that conversation is possible on the new call.
5. After completing procedure 4, place the new call on hold, and retrieve the
multiparty call (2 SEND). Check that conversation is possible between all parties of
the multiparty call.
five parties can speak to each other.
7. After completing procedure 6, place the multiparty call on hold, and make a new
outgoing call (DN SEND).
six parties can speak to each other
9. After completing procedure 8, arrange for a new incoming call to be made, place
the multiparty on hold, and accept the new incoming call (2 SEND).
10. After completing procedure 9, dial the code 3 SEND to join the calls. Check that
the attempt fails, and that the mobile indicates that the maximum number of
participants has been exceeded.
11. After completing procedure 10, create a private communication with one of the
distant parties (Code 2X SEND), placing the remainder of the parties on hold. Check
that conversation is possible with the chosen party, and that the correct party has
been selected.
12. After completing procedure 11, make the distant party release the call during
private conversation. Check that the call can be switched back to the multi party call
(2 SEND).
13. After completing procedure 12, select another party for a private conversation (2X
SEND) and make this party release the call during the attempt to switch to the private
conversation. Check that the call can be switched back to the multi party call (2
SEND).
14. After completing procedure 13, have one of the distant parties clear the call.
Ensure that the multiparty call is not disturbed for the remaining participants.
EXPECTED RESULT:
The MS behaves as described in the test procedure.
ADDITIONAL INFO:
For CL:
Repeat procedure with multiconference started with:
- call generated by DuT
- call received by DuT
TC-HSDPA-ASYNC- Receiving USSD DESCRIPTION:

013a while downloading a 1. Download a file with active HS-DSCH reception.
file with active HS- 2. Send USSD while the file is being downloaded.
DSCH reception 3. Check that the DuT receives USSD while the file is being downloaded.
EXPECTED RESULT:
USSD is received successfully.
TC-HSDPA-ASYNC- Receiving VT call DESCRIPTION:

007a while browsing from 1. Open DuT's browser.
the DuT. Answer 2. Start browsing with the DuT.
incoming call and 3. Make a VT call to the DuT with another UE.
continue browsing 4. When the call rings, answer the call.
5. End the call.
6. Browse some more.
7. End the browsing.
EXPECTED RESULT:
When the call rings, it shall be possible to see the caller's number and answer it.
The browsing goes on normally after answering, along with the VT call.
After hanging up the VT call, check that the browsing still works.
After ending the browsing, caller number is stored in the list of received calls.

008a while browsing from 1. Open the DuT's browser.
the DuT. Reject 2. Start browsing.
incoming call and 3. Make a VT call to the DuT with another UE.
continue browsing 4. When the call rings, reject the call.
5. Stop browsing.
EXPECTED RESULT:
When the call rings, it shall be possible to see the caller's number and reject it. The
browsing goes on normally after rejecting the call.
After stopping the browsing, check that the caller number is stored in the list of
received calls.
TC-HSDPA-ASYNC- Receiving VT call PRECONDITIONS:

005a while downloading a The DuT is switched on in HSDPA enabled UTRAN environment with sufficient
file with active HS- coverage, so no cell reselection to GSM is performed.
DSCH reception. To perform this test case properly, suitable Monitor software is needed.
Answer incoming call DESCRIPTION:
and download 1. Make a Video and HSDPA PS-data calls with 3G DuT according to the table below.
continues The first call is mobile originated call. The second call is mobile terminated call.
2. Ensure that the Video call success and the quality is undisturbed.
3. In data call, download a large file (e.g. with FTP) parallel with Video call.
4. Monitor the data flow with suitable software.
5. End the first call according to the table’s column “End First”.
6. Ensure that the remaining call is not disturbed.
Scenario First Call Second Call
End First
C MO PS-data call MT Video call
PS-data call
D MO PS-data call MT Video call
Video call
EXPECTED RESULT:
The Video call continues and the quality is undisturbed.
The HSDPA PS-data call continues and the data stream is not interrupted.
After ending the other call, the first call continues and works normally.
ADDITIONAL INFO:
Ensure that when the “second call” is initiated that the PS data call is not re-
configured or downgraded to a R99 bearer.

006a while downloading a 1. Download a file.
file with active HS- 2. Receive a VT call while downloading a file with active HS-DSCH reception.
DSCH reception. 3. Reject incoming call.
Reject incoming call EXPECTED RESULT:
VT call must be rejected, and the download must continue.
In case that the DuT does not support videotelephony, the call must be automatically
rejected.
There should be no impact in data transfer (if there is no reconfiguration to R99).
TC-HSDPA-ASYNC- Sending USSD while DESCRIPTION:

016a downloading a file 1. Download a file with active HS-DSCH reception.
with active HS-DSCH 2. Send USSD while the file is being downloaded.
reception EXPECTED RESULT:
The USSD is sent successfully.
TC-HSDPA-ASYNC- Sending MM while PRECONDITIONS:

018a downloading a file The DuT is switched on in HSDPA enabled UTRAN environment with sufficient
with active HS-DSCH coverage, so no cell reselection to GSM is performed.
reception DESCRIPTION:
1. Make a HSDPA-data call with 3G DuT.
2. While downloading a large file (e.g. with FTP), send a mobile originated MM.
EXPECTED RESULT:
MM shall be sent successfully.
ADDITIONAL INFO:
Here we have different possibilities:
- DuT uses the same APN for browsing and MM
-> Then MM must be sent without stopping or suspending any other traffic.
- DuT uses different APN for browsing and MM. Two alternatives arise:
-> UTRAN supports more than one simulataneous active PDP contexts:
+ MM must be properly sent without closing any other PDP context, or stop
browsing
-> UTRAN supports just one simulataneous active PDP context:
+ Then, the active PDP context must remain open, and MM must be sent
automatically right after the previous PDPc is closed.
It is possible, if multiple PDPc were not supported in HSDPA, that DuT would be
reconfigured to R99 to sent the MM.
TC-HSDPA-MOBIL- 3TC to 3TH - Inter- PRECONDITIONS:

017a frequency HO There must be an appropriate number of 2G and 3G cells available on the same
PLMN. The RAB to be tested should be active, and available in all parts of the test
route.
DESCRIPTION:
The DuT should perform handovers as requested by the network, and behave as
expected from the user perspective without losing services.
The DuT shall download a file successfully.
With the active file download, move from one R99 cell to a HSDPA cell that belong to
the same RNC.
With a logging tool, check the active cell, the levels of the monitored cells and the
events sent in the Measurement Report messages.
It is a MultiRAB test, the combination of Voice + PS Data should be used. This
service should be available to the user regardless of handovers. The data rate shall
be as expected for the data bearer type assigned by the network throughout the test.
This scenario is designed to test softer/soft handovers when RNC is shared. Node B
is different and frequency is different.
1. Move between the coverage areas of different cells, ideally on a long test route.
2. Verify that the test route should contain as many of the scenario indicated.
3. Ensure that the DuT performs reselections/handovers as expected.
4. During the test drive it is imperative the DuT remains in service at all times, that
the RAB in question is maintained throughout the test route.
5. Check that the DuT is always able to receive mobile terminating calls.
EXPECTED RESULT:
Check that the file download is not interrupted at any moment during the handover
(use the throughput meter).
The DuT should perform reselections/handovers correctly, without losing service, and
all relevant RABs should be available throughout the test route.
ADDITIONAL INFO:
Please, take into account that maybe this test case would not be able to be executed
because of one of following causes:
- Network does not support this feature yet
- This feature is not enabled (although supported) in the network
- Network configuration issues.
TC-HSDPA-MOBIL- 3TC to 3TH - Intra- PRECONDITIONS:

route.
DESCRIPTION:
Check intra-frequency and RL deletion.
This scenario is designed to test soft/softer handovers when RNC is shared, Node B
is shared or not, sector is different and frequency is shared.
EXPECTED RESULT:
TC-HSDPA-MOBIL- 3TC to 3TH - Inward PRECONDITIONS:

031a Mobility (transition There must be an appropriate number of 2G and 3G cells available on the same
from CELL_DCH to PLMN. The RAB to be tested should be active, and available in all parts of the test
HS-DSCH) during route.
Multi-call (intra- 2 cells (A and B ) are available belonging to different Node-Bs and same frequency.
frequency , inter- Only cell A is HSDPA enabled.
NodeB scenario) - RL DuT is HSDPA capable.
deletion Both cells belong to the Active Set.
DESCRIPTION:
Check the transition from CELL_DCH to HS-DSCH during a Multi-call.
It is a MultiRAB test, the combination of Voice + PS Data should be used. All services
should be available to the user regardless of handovers. The data rate shall be as
expected for the data bearer type assigned by the network throughout the test.
This scenario is designed to test handovers when Node B is different and frequency
is the same.
EXPECTED RESULT:
TC-HSDPA-MOBIL- 3TH to 3TC - Inter- PRECONDITIONS:

011a frequency with Blind There must be an appropriate number of 2G and 3G cells available on the same
HO (without PLMN. The RAB to be tested should be active, and available in all parts of the test
Compressed Mode) route.
DESCRIPTION:
Check Blind handover ,without Compressed Mode.
This scenario is designed to test hard handovers when RNC is shared, Node B is
shared, antenna is the same, frequency is different .
EXPECTED RESULT:
Check that the file download is interrupted for a short time (very few seconds, less
than five seconds and probably around 1 second) during the blind handover (use the
throughput meter).
ADDITIONAL INFO:
TC-HSDPA-MOBIL- 3TH to 3TC - Inter- PRECONDITIONS:

012a frequency (with There must be an appropriate number of 2G and 3G cells available on the same
Compressed Mode) PLMN. The RAB to be tested should be active, and available in all parts of the test
route.
DESCRIPTION:
Check Compressed Mode.
different, frequency is different and Compressed Mode is activated.
EXPECTED RESULT:
ADDITIONAL INFO:
TC-HSDPA-MOBIL- 3TH to 3TC - Intra- PRECONDITIONS:

route.
64 kbps HSDPA-associated uplink DCH return channel is used
DESCRIPTION:
Check that transition from CELL_DCH to HS-DSCH is implemented with the optional
HSDPA resumption timer.
Check intra-frequency and RL addition.
This scenario is designed to test softer/soft handovers when RNC is shared, Node B
is shared or not, sector is different and frequency is shared. Cell B power about 10
dB less than cell A, so DuT has cell A as initial serving HS-DSCH cell.
EXPECTED RESULT:
TC-HSDPA-MOBIL- 3TH to 3TC - Outward PRECONDITIONS:

from HS-DSCH to PLMN. The RAB to be tested should be active, and available in all parts of the test
CELL_DCH) during route.
Multi-call (intra- 2 cells (A and B ) are available belonging to different Node-Bs and same frequency
frequency , inter- Only cell A is HSDPA enabled
NodeB scenario) - RL DuT is HSDPA capable
addition Only cell A belongs to the Active Set
DESCRIPTION:
Check the transition from HS-DSCH to CELL_DCH during a Multi-call.
This scenario is designed to test handovers when It is a inter-NodeB and intra-
frequency scenario. Cell B power about 10 dB less than cell A, so DuT has cell A as
initial serving HS-DSCH cell.
EXPECTED RESULT:

Multi-call (intra- 2 cells (A and B ) are available belonging to same Node-B and same frequency
frequency , intra- Only cell A is HSDPA enabled
deletion Both cells belong to the Active Set
DuT has cell A as initial serving HS-DSCH cell
DESCRIPTION:
This scenario is designed to test handovers when It is a intra-NodeB and intra-
frequency scenario.
EXPECTED RESULT:

Multi-call (intra- 2 cells (A and B ) are available belonging to different Node-Bs and same frequency
frequency , inter- Only cell A is HSDPA enabled
deletion Both cells belong to the Active Set
DESCRIPTION:
frequency scenario.
EXPECTED RESULT:
ADDITIONAL INFO:
Transition from CELL_DCH to HS-DSCH is implemented with the optional HSDPA
resumption timer.
TC-HSDPA-MOBIL- 33TH - Engaged in a PRECONDITIONS:

005a voice call and data There must be an appropriate number of 2G and 3G cells available on the same
transfer (CELL_DCH PLMN. The RAB to be tested should be active, and available in all parts of the test
State). Inter- route.
frequency with DESCRIPTION:
Compressed Mode. The DuT should perform handovers as requested by the network, and behave as
The DuT shall be engaged in voice call and data transfer (CELL_DCH State).
Check inter-frequency with Compressed Mode.
Verify that the entry in CM and HO are done.
This test should be carried out to invoke hard handovers in case the frequency
changes between the 3G cells.
EXPECTED RESULT:
TC-HSDPA-MOBIL- 33TH - LA Update PRECONDITIONS:

008a and RA Update after There must be an appropriate number of 2G and 3G cells available on the same
3G to 3G handover PLMN. The RAB to be tested should be active, and available in all parts of the test
route.
DESCRIPTION:
To perform this test, a scenario is needed where a Location Area change and
Routing Area change within 3G coverage can happen.
Check that after of doing soft handover, keep the voice call active for 30 seconds and
hung up (these 30 seconds are to distinguish clearly between the “handover time”
and the “voice call end time”). Then wait until the file downloading is resumed and
leave the downloading active still for one minute more (to distinguish clearly the
“voice call end time” from the “download end time”) and then stop all the
downloading/uploading activity without deactivating the PDP context.
The scenario is designed to test softer handovers. Test shall include handovers
within a RAT with cells supporting PS(R99), HSDPA and/or HSUPA(EUL).
EXPECTED RESULT:
Check that two messages are sent by the DuT after the handover is performed and
the voice call is ended, but before the download resumes, that is, around t = 31s.:
-“Location Area update request” followed by a “Location Area update accept”
-“Routing Area update request” followed by a “Routing Area update accept”.
ADDITIONAL INFO:
In seconds:
- “handover time”: t = 0 s.
- Voice call resumes: t = 0.1 s.
- “voice call end time”: t = 30 s.
- Download resumes: t = 45 s.
- “download end time”: t = 105 s.
TC-HSDPA-MOBIL- 33TH - Engaged in a DESCRIPTION:

025a voice call and data The DuT should perform handovers as requested by the network, and behave as
transfer (CELL_DCH expected from the user perspective without losing services.
State). Inter- The DuT shall download a file successfully.
frequency with Blind Check Blind handover, without Compressed Mode.
HO (without It is a MultiRAB test, the combination of Voice + PS Data should be used. This
Compressed Mode) service should be available to the user regardless of handovers. The data rate shall
This scenario is designed to test hard handovers when Node B is shared or not, RNC
is shared and frequency is different. It is an Interfrequency test.
EXPECTED RESULT:
throughput meter).
ADDITIONAL INFO:
TC-HSDPA-MOBIL- 33TH - Intra- PRECONDITIONS:

route.
DESCRIPTION:
This scenario is designed to test soft/softer handovers when RNC is shared ,Node B
is shared or not, antenna is different, sector is different and frequency is shared.
EXPECTED RESULT:
ADDITIONAL INFO:
TC-HSDPA-MOBIL- 3VC to 3VH - Inter- PRECONDITIONS:

route.
DESCRIPTION:
It is a MultiRAB test, the combination of Video Telephony + PS Data should be used.
This service should be available to the user regardless of handovers. The data rate
shall be as expected for the data bearer type assigned by the network throughout the
test.
This scenario is designed to test soft handovers when RNC is shared. Node B is
different and frequency is different.
EXPECTED RESULT:
ADDITIONAL INFO:
TC-HSDPA-MOBIL- 3VC to 3VH - Intra- PRECONDITIONS:

route.
DESCRIPTION:
test.
This scenario is designed to test soft/softer handovers when RNC is shared. Node B
EXPECTED RESULT:
ADDITIONAL INFO:
TC-HSDPA-MOBIL- 3VH to 3VC - Inter- PRECONDITIONS:

DESCRIPTION:
Check Blind handover, without Compressed Mode.
test.
is shared, antenna is the same and frequency is different.
EXPECTED RESULT:
throughput meter).
ADDITIONAL INFO:
TC-HSDPA-MOBIL- 3VH to 3VC - Inter- PRECONDITIONS:

015a frequency (with There must be an appropriate number of 2G and 3G cells available on the same
route.
DESCRIPTION:
Check Compressed Mode.
test.
This scenario is designed to test softer/soft handovers when RNC is shared. Node B
is different, frequency is different and Compressed Mode is activated.
EXPECTED RESULT:
ADDITIONAL INFO:
TC-HSDPA-MOBIL- 3VH to 3VC - Intra- PRECONDITIONS:

route.
DESCRIPTION:
test.
EXPECTED RESULT:
ADDITIONAL INFO:
TC-HSDPA-MOBIL- 33VH - Engaged in a PRECONDITIONS:

006a videotelephony call There must be an appropriate number of 2G and 3G cells available on the same
and data transfer PLMN. The RAB to be tested should be active, and available in all parts of the test
(CELL_DCH State). route.
Inter-frequency with DESCRIPTION:
Compressed Mode, The DuT should perform handovers as requested by the network, and behave as
entry in CM and HO expected from the user perspective without losing services.
done The DuT shall be engaged in videotelephony call and data transfer (CELL_DCH
State).
test.
EXPECTED RESULT:
TC-HSDPA-MOBIL- 33VH - Inter- PRECONDITIONS:

DESCRIPTION:
test.
This scenario is designed to test hard handovers when RNC is shared ,Node B is
shared or not and frequency is shared.
EXPECTED RESULT:
throughput meter).
ADDITIONAL INFO:
TC-HSDPA-MOBIL- 33VH - Intra- PRECONDITIONS:

route.
DESCRIPTION:
test.
EXPECTED RESULT:
ADDITIONAL INFO:
TC-HSDPA-MOBIL- 3IC to 3IH - Intra- PRECONDITIONS:

010a frequency reselection There must be an appropriate number of 2G and 3G cells available on the same
route.
DESCRIPTION:
With the active file download, the DuT shall move from one R99 cell to a HSDPA cell
that belong to the same RNC.
It is a PS Data test, the DuT should be actively transmitting data before and after the
CCO. The session should be viable after reselection and the DuT should still be able
to receive mobile terminating calls. The data rate shall be as expected for the data
bearer type assigned by the network throughout the test.
EXPECTED RESULT:
ADDITIONAL INFO:
TC-HSDPA-MOBIL- 3IC to 3IH - Inter- PRECONDITIONS:

route.
DESCRIPTION:
With the active file download, move from one R99 cell to a HSDPA cell with a
different frequency.
With a logging tool, check the events sent in the Measurement Report messages.
This scenario is designed to test softer handovers when RNC is shared, Node B is
shared or not, sector is different and frequency is different.
EXPECTED RESULT:
ADDITIONAL INFO:
TC-HSDPA-MOBIL- 33IH - Inward Mobility PRECONDITIONS:

029a (transition from There must be an appropriate number of 2G and 3G cells available on the same
CELL_DCH to HS- PLMN. The RAB to be tested should be active, and available in all parts of the test
DSCH) during a PS route.
data call (inter- 2 cells (A and B ) are available belonging to different Node-Bs and different
frequency , inter- frequencies
NodeB scenario) only cell B is HSDPA enabled
DuT is HSDPA capable
DuT is performing FTP data transfer in DL
DESCRIPTION:
Check the transition from CELL_DCH to HS-DSCH during a PS call.
is different. Cell B power about 10 dB less than cell A, so DuT has cell A as serving
cell.
EXPECTED RESULT:
TC-HSDPA-MOBIL- 33IH - Inward Mobility PRECONDITIONS:

030a (transition from There must be an appropriate number of 2G and 3G cells available on the same
CELL_DCH to HS- PLMN. The RAB to be tested should be active, and available in all parts of the test
DSCH) during a PS route.
call (intra-frequency , 2 cells (A and B ) are available belonging to different Node-Bs and same frequency
inter-NodeB scenario) Only cell A is HSDPA enabled
- RL deletion DuT is HSDPA capable
Both cells belong to the Active Set
DuT is performing FTP data transfer in DL on R99
DESCRIPTION:
Check the transition from CELL_DCH to HS-DSCH during a PS call.
This scenario is designed to test handovers when it is a inter-NodeB scenario.
EXPECTED RESULT:
TC-HSDPA-MOBIL- 3IH to 3IC - Inter- PRECONDITIONS:

DESCRIPTION:
shared, antenna is the same and frequency is different. It is an interfrequency test.
EXPECTED RESULT:
throughput meter).
ADDITIONAL INFO:
TC-HSDPA-MOBIL- 33IH - Outward PRECONDITIONS:

CELL_DCH) during a route.
PS data call (inter 2 cells (A and B ) are available belonging to different frequencies.
NodeB and inter- Only cell A is HSDPA enabled.
frequency scenario) DuT is HSDPA capable.
DuT is performing FTP data transfer in DL.
DESCRIPTION:
Check the transition from HS-DSCH to CELL_DCH during a PS call.
This scenario is designed to test handovers when It is a inter-NodeB and inter-
EXPECTED RESULT:

PS data call (inter- 2 cells (A and B ) are available belonging to different Node-Bs and same frequency
NodeB, intra- Only cell A is HSDPA enabled
frequency scenario) - DuT is HSDPA capable
RL addition Only cell A belongs to the Active Set
DESCRIPTION:
EXPECTED RESULT:

PS data call (intra- 2 cells (A and B ) are available belonging to same Node-B and same frequency
RL Deletion Both cells belong to the Active Set
DESCRIPTION:
frequency scenario.
EXPECTED RESULT:

PS data call (inter- 2 cells (A and B ) are available belonging to different Node-Bs and same frequency
RL Deletion Both cells belong to the Active Set
DESCRIPTION:
frequency scenario.
EXPECTED RESULT:

PS data call (intra- 2 cells (A and B ) are available belonging to same Node-B and same frequency
RL addition Only cell A belongs to the Active Set
DESCRIPTION:
Check the transition from HS-DSCH to CELL_DCH during a PS data call.
initial serving HS-DSCH cell
EXPECTED RESULT:
TC-HSDPA-MOBIL- 33IH - Reselection in PRECONDITIONS:

004a CELL_DCH (CS There must be an appropriate number of 2G and 3G cells available on the same
Attached). Inter- PLMN. The RAB to be tested should be active, and available in all parts of the test
frequency with route.
Compressed Mode, DESCRIPTION:
entry in CM and HO The DuT should perform handovers as requested by the network, and behave as
done expected from the user perspective without losing services.
The DuT shall do reselection in CELL_DCH (CS attached).
EXPECTED RESULT:
TC-HSDPA-MOBIL- 33IH - Inter-frequency PRECONDITIONS:

007a - Inter-RNC serving There must be an appropriate number of 2G and 3G cells available on the same
HS-DSCH cell change PLMN. The RAB to be tested should be active, and available in all parts of the test
route.
64 kbps HSDPA-associated uplink DCH return channel is used.
DESCRIPTION:
This test should be carried out to invoke handovers in case the frequency and RNC
change between the 3G cells.
EXPECTED RESULT:
ADDITIONAL INFO:
The DuT with a HS-DSCH transport channel allocated can have only one cell in the
active set at a time, that is, the size of the active set is limited to one.
Because of this, the RNC does not add cells to the active set based on reporting
event 1A when a HS-DSCH transport channel is allocated to the DuT, but utilises the
event 1A as a trigger for a HS-DSCH MAC-d flow release and transition to the
Cell_FACH state.
The DuT performs a standard cell reselection to select the strongest cell in the
Cell_FACH state. After Cell Update procedure HS-DSCH MAC-d flow can be setup
and HS-DSCH reallocated.
TC-HSDPA-MOBIL- 33IH - LA Update and PRECONDITIONS:

009a RA Update after 3G to There must be an appropriate number of 2G and 3G cells available on the same
3G Intra-frequency PLMN. The RAB to be tested should be active, and available in all parts of the test
handover route.
DESCRIPTION:
To perform this test, a scenario is needed where a Location Area change and
Routing Area change within 3G coverage can happen.
Check that after of doing soft handover, keep the file downloading active still for one
minute more (to distinguish clearly if the LAU is sent after the HO or after ending the
call) and then stop all the downloading/uploading activity without deactivating the
PDP context.
This scenario is designed to test softer handovers. Test shall include handovers
within a RAT with cells supporting PS(R99), HSDPA and/or HSUPA(EUL).
EXPECTED RESULT:
Check that two messages are sent by the DuT after the handover is performed, but
before the download resumes:
-“Location Area update request” followed by a “Location Area update accept”
-“Routing Area update request” followed by a “Routing Area update accept”.
TC-HSDPA-MOBIL- 33IH - Inter-frequency DESCRIPTION:

022a HO (64, 128 or 384 The DuT should perform handovers as requested by the network, and behave as
kbps-HS kbps RAB) expected from the user perspective without losing services.
with Compressed The DuT shall download a file successfully.
Mode. With the active file download, move from one 3G cell to another 3G cell with a
different frequency.
CCO. All supported data rates should be tested. Test should be repeated with the
DuT in DCH, FACH, and PCH modes. The session should be viable after
reselections in each of these states, and the DuT should still be able to receive
mobile terminating calls. The data rate shall be as expected for the data bearer type
assigned by the network throughout the test.
Tests should be carried out to invoke hard handovers in case the frequency changes
between the 3G cells when Node B is shared or not, RNC is shared and frequency is
shared using 64, 128 or 384 kbps/HS kbps RAB.
EXPECTED RESULT:
than five seconds and probably around 1 second) during the handover (use the
throughput meter).
ADDITIONAL INFO:
With a logging tool, check the events sent in the Me asurement Control messages
and Measurement Report messages.
Check the following RRC messages:
- Event 2d indicating bad coverage of the first frequency.
- Physical Channel reconfiguration message sent by the network and the answer
(Ph CH Reconf Complete) from the phone confirming the entry in CM.
- Measurement Control messages received with conditions for events 2a and 2a’ ,
or only 2a (depends on Network vendor).
- Measurement Report sent by the TUT reporting cell (of the other frequency) that
triggers event 2a.
- Physical Ch Reconfiguration from NW and Ph CH Reconf Complete after IFHO
successful.
TC-HSDPA-MOBIL- 33IH - Intra- PRECONDITIONS:

026a frequency, Intra-Node There must be an appropriate number of 2G and 3G cells available on the same
B serving HS-DSCH PLMN. The RAB to be tested should be active, and available in all parts of the test
cell change route.
2 cells (A and B ) are available belonging to same Node-B and same frequency
Both cells are HSDPA enabled
DESCRIPTION:
The DuT shall download successfully.
Check Intra-Node B serving HS-DSCH cell change
This scenario is designed to test handovers when Nodes B and frequencies are the
same.
EXPECTED RESULT:
ADDITIONAL INFO:
A DuT with a HS-DSCH transport channel allocated can have only one cell in the
active set at a time, that is, the size of the active set is limited to one. Because of this,
the RNC does not add cells to the active set based on reporting event 1A when a HS-
DSCH transport channel is allocated to the DuT, but utilises the event 1A as a trigger
for a HS-DSCH MAC-d flow release and transition to the Cell_FACH state. The DuT
performs a standard cell reselection to select the strongest cell in the Cell_FACH
state. After Cell Update procedure HS-DSCH MAC-d flow can be setup and HS-
DSCH reallocated.
TC-HSDPA-MOBIL- 33IH - Intra- PRECONDITIONS:

027a frequency, Inter-Node There must be an appropriate number of 2G and 3G cells available on the same
B serving HS-DSCH PLMN. The RAB to be tested should be active, and available in all parts of the test
cell change route.
2 cells (A and B ) are available belonging to different Node-Bs and same frequency
DESCRIPTION:
Check Inter-Node B serving HS-DSCH cell change
is the same.
EXPECTED RESULT:
ADDITIONAL INFO:
DSCH reallocated.
TC-HSDPA-MOBIL- 33IH - Intra-frequency PRECONDITIONS:

028a - Inter-RNC serving There must be an appropriate number of 2G and 3G cells available on the same
HS-DSCH cell change PLMN. The RAB to be tested should be active, and available in all parts of the test
route.
2 cells (A and B ) are available belonging to different RNCs but same frequency
DESCRIPTION:
Check Inter-RNC serving HS-DSCH cell change
Check intra-frequency.
This scenario is designed to test handovers when RNC is different and frequency is
the same.
EXPECTED RESULT:
ADDITIONAL INFO:
DSCH reallocated.
TC-HSDPA-MOBIL- 33IH - Inter-frequency PRECONDITIONS:

042a with Blind HO (without There must be an appropriate number of 2G and 3G cells available on the same
route.
DESCRIPTION:
With the active file download, move from one HSDPA cell to another HSDPA cell with
a different frequency.
This scenario is designed to test hard handovers when RNC is shared ,Node B is
shared or not and frequency is different. It is an Interfrequency test.
EXPECTED RESULT:
throughput meter).
ADDITIONAL INFO:
In the Comments field, note down the number of seconds that the download is
interrupted.
TC-HSDPA-MLTRB- Start PKT call, make PRECONDITIONS:

002a MO VT call, end PKT The DuT is switched on in HSDPA enabled UTRAN environment with sufficient
call, end MO VT call coverage, so no cell reselection to GSM is performed.
To perform this test case properly, suitable Monitor software is needed.
DESCRIPTION:
1. Make a Video and HSDPA PS-data calls with 3G DuT according to the table
below.The first call is mobile originated call. The second call is mobile originated call.
End First
B MO PS-data call MO Video call
PS-data call
EXPECTED RESULT:
ADDITIONAL INFO:
TC-HSDPA-MLTRB- Start MO VT call, PRECONDITIONS:

005a make PKT call, end The DuT is switched on in HSDPA enabled UTRAN environment with sufficient
MO VT call, end PKT coverage, so no cell reselection to GSM is performed.
call To perform this test case properly, suitable Monitor software is needed.
DESCRIPTION:
1. Make a Video and HSDPA PS-data calls with 3G DuT according to the table below.
The first call is mobile originated call. The second call is mobile originated call.
End First
A MO Video call MO PS-data call
Video call
EXPECTED RESULT:
ADDITIONAL INFO:
TC-HSDPA-MLTRB- Start PKT call, make PRECONDITIONS:

006a MO VT call, end MO The DuT is switched on in HSDPA enabled UTRAN environment with sufficient
VT call, end PKT call coverage, so no cell reselection to GSM is performed.
To perform this test case properly, suitable Monitor software is needed.
DESCRIPTION:
1. Make a Video and HSDPA PS-data calls with 3G DuT according to the table
below.The first call is mobile originated call. The second call is mobile originated call.
5. End the first call according to the table's column 'End First'.
End First
Not in GCF MO PS-data call MO Video call
Video call
EXPECTED RESULT:
ADDITIONAL INFO:
Ensure that when the 'second call' is initiated that the PS data call is not re-
TC-HSDPA-MLTRB- Start MO VT call, PRECONDITIONS:

008a make PKT call, end The DuT is switched on in HSDPA enabled UTRAN environment with sufficient
PKT call, end MO VT coverage, so no cell reselection to GSM is performed.
call To perform this test case properly, suitable Monitor software is needed.
DESCRIPTION:
1. Make a Video and HSDPA PS-data calls with 3G DuT according to the table below.
The first call is mobile originated call. The second call is mobile originated call.
5. End the first call according to the table's column 'End First'.
End First
Not in GCF MO Video call MO PS-data call
PS-data call
EXPECTED RESULT:
ADDITIONAL INFO:
Ensure that when the 'second call' is initiated that the PS data call is not re-
TC-HSDPA-MLTRB- Simultaneous UL-DL PRECONDITIONS:

011a FTP Throughput for The DuT is switched on in HSDPA enabled UTRAN environment with sufficient FDD
HSDPA PS RAB in coverage, so no cell reselection to GSM is performed.
multi-RAB scenario DESCRIPTION:
(PS + CS Video) 1. Establish a Video call.
2. Establish a dial-up networking session.
3. Start an FTP download. Use an uncompressible file larger than 20Mbytes.
4. Simultaneously start an FTP upload. Use an uncompressible file larger than
5Mbytes.
5. Measure the throughput of both the upload and download using a suitable
application.
EXPECTED RESULT:
The DuT shall be able to present average throughput values proportional to the
HSDPA capability of the device and the HSDPA uplink available on the cell used.
ADDITIONAL INFO:
The TCP RX window size of both the laptop and FTP server shall be set
appropriately so that optimum simultaneous Uplink and Downlink performance is
achieved. If the TCP RX window size of the FTP server cannot be set to an optimum
configuration
TC-HSDPA-MLTRB- 32VH - Handover to DESCRIPTION:

013a 2G from CELL_DCH 1. Download a very large ZIP file or several files in parallel if the server for one file
HS+ VT. VT is doesn’t provide enough throughput. 2. With the active download, make a video call.
dropped, PS 3. When the VT call starts, check that the PS download rate will be lowered.
continues in 2G 4. Activate the context and start downloading the files.
5. Make a video call to the demo number.
6. With the active file download and video call, move from one 3G cell to a 2G cell.
7. Wait until the download application resumes the download and the ZIP file is
completely downloaded.
8. Check that the video call is dropped.
9. Check that the file download is interrupted for a long time (around 1 minute) during
the reselection (use the throughput meter to measure the seconds and note down
the seconds of interruption).
EXPECTED RESULT:
The video call is active even with very bad quality until it is dropped due to a Radio
Link Failure. The state changes from Cell_DCH to Idle.
The DuT reselects to 2G.
Pagings calling the phone in 2G to resume the file download.
Check the downloaded ZIP file integrity opening it. If some bytes were missed, the
unzipping application would indicate it.
ADDITIONAL INFO:
TC-HSDPA-PSDAT- 3IC to 3IH - Cell_DCH DESCRIPTION:

003a R99 to Cell_DCH R5 The DuT shall reselect from Cell_DCH R99 to Cell_DCH R5. Start of HS-DSCH
Inter-frequency reception + DCH R99 transmission, within same sector but different frequency.
Check that the DuT can change from state 3IC to 3IH
1. Start data download under R99 coverage.
2. Wait for reselection to Cell_DCH R5.
3. Check that data download is resumed.
EXPECTED RESULT:
The data transfer is resumed after reselection to R5 DCH
ADDITIONAL INFO:
Some network configuration parameters may prevent the execution of this testcase
TC-HSDPA-PSDAT- 3IH to 3IC - Cell_DCH DESCRIPTION:

004a R5 to Cell_DCH R99 The DuT shall reselect from Cell_DCH R5 to Cell_DCH R99. Stop of HS-DSCH
Inter-frequency reception + DCH R99 transmission, within same sector but different frequency.
Check that the DuT can change from state 3IH to 3IC.
1. A data download is in progress under R5 coverage.
2. Wait for reselection to DCH R99.
3. Check that data download is resumed.
EXPECTED RESULT:
The data transfer is resumed after reselection to DCH R99
ADDITIONAL INFO:
Some network configuration parameters may prevent the execution of this testcase.
TC-HSDPA-PSDAT- 3IC to 3IH - Cell_DCH DESCRIPTION:

001a R99 to Cell_DCH R5 The DuT shall reselect from Cell_DCH R99 to Cell_DCH R5. Start of HS-DSCH
Intra-frequency reception + DCH R99 transmission, within same sector and same frequency.
Check that the DuT can change from state 3IC to 3IH
1. Start data download under R99 coverage.
2. Wait for reselection to Cell_DCH R5.
3. Check that data download is resumed .
EXPECTED RESULT:
The data transfer is resumed after reselection to R5 DCH
ADDITIONAL INFO:
Some network configuration parameters may prevent the execution of this testcase
TC-HSDPA-PSDAT- 3IH to 3IC - Cell_DCH DESCRIPTION:

002a R5 to Cell_DCH R99 The DuT shall reselect from Cell_DCH R5 to Cell_DCH R99. Stop of HS-DSCH
Intra-frequency reception + DCH R99 transmission, within same sector and same frequency.
Check that the DuT can change from state 3IH to 3IC.
1. A data download is in progress under R5 coverage.
2. Wait for reselection to DCH R99.
3. Check that data download is resumed .
EXPECTED RESULT:
The data transfer is resumed after reselection to DCH R99
ADDITIONAL INFO:
Some network configuration parameters may prevent the execution of this test case.
TC-HSDPA-PRFMC- Simultaneous FTP PRECONDITIONS:

003a Download 200 MB The DuT is IMSI attached and PS attached on an HSDPA enabled cell in its 3G
and Upload 50 MB - HPLMN
Percentage The DuT has a PDP context already active by means of a dial-up networking session.
degradation of DESCRIPTION:
download rate with 1. Verify that a dial-up networking session is already established.
simultaneous upload 2. Start an FTP download. Use an uncompressible file larger than 200Mbytes.
50Mbytes.
application.
EXPECTED RESULT:
The DuT shall be able to present average throughput values proportional to the
HSDPA capability of the device and the HSDPA uplink RAB enabled for the cell.
ADDITIONAL INFO:
configuration by the tester, then UDP protocol may be utilised to perform this test
case.
TC-HSDPA-PRFMC- UL FTP Throughput PRECONDITIONS:

005a on 64kbps HSDPA- DuT is HSDPA capable.
associated uplink The initial bit rate for the HSDPA-associated uplink DCH return channel is set to 64
DCH return channel kbps.
DESCRIPTION:
1. Upload a file.
2. Measure the average uplink throughput on an HSDPA enabled cell when the 64
kbps HSDPA-associated uplink DCH return channel is used for data upload.
EXPECTED RESULT:
The Uplink FTP Throughput should be close to 64 kbps

006a on 128 kbps HSDPA- DuT is HSDPA capable.
associated uplink The initial bit rate for the HSDPA-associated uplink DCH return channel is set to 128
DCH return channel kbps.
DESCRIPTION:
1. Upload a file.
2. Measure the average uplink throughput on an HSDPA enabled cell when the 128
kbps HSDPA-associated uplink DCH return channel is used for data upload.
EXPECTED RESULT:
The Uplink FTP Throughput should be close to 128 kbps

007a on 384 kbps HSDPA- Testlab HPLMN UICCv2/v3 (384/3648kbit/s UL/DL)
associated uplink 3G DuT
DCH return channel Notebook/ PC
DuT PC Suite/ connection software
Data Speed Monitor Tool : NetPerSec
HPLMN Nokia UTRAN+HSDPA cell in Testlab
DESCRIPTION:
1. Power on DuT
2. Register to Testlab HPLMN Nokia UTRAN+HSDPA cell
3. Establish a PS Internet connection with the DuT with an available build in
connectivity port (e.g. IrDA,
Bluetooth, cable)
4. Start a DL
5. Measure with a data speed monitor tool (NetPerSec) the DL speed average
6. Start additionally a UL
7. Measure with a data speed monitor tool (NetPerSec) the DL+UL speed average
8. Stop the DL
9. Measure with a data speed monitor tool (NetPerSec) the UL speed average
10. Stop the UL
11. Power off DuT
EXPECTED RESULT:
A HSDPA DuT shall be able to establish a PS internet connection with a UL/DL
384/3648kbs RAB
A UMTS DuT shall be able to establish a PS internet connection with a UL/DL
384/384 kBit/s RAB
The DL and UL are stable and do not drop
TC-HSDPA-QOSMN- Establishing PDP DESCRIPTION:

001a context with 1. Follow manufacturer's procedure if the DuT supports this feature.
Interactive QoS 2. Check also if the network supports this feature.
3. Establish PDP context with Interactive QoS.
4. Check QoS provided by the network, the DuT response and the data connection.
EXPECTED RESULT:
PDPc with interactive QoS properly established.

Background QoS 2. Check also if the network supports this feature.
3. Establish PDP context with Background QoS.
EXPECTED RESULT:
PDPc with background QoS properly established.

Streaming QoS 2. Check also if the network supports this feature.
3. Establish PDP context with Streaming QoS.
EXPECTED RESULT:
PDPc with streaming QoS properly established.

Conversational QoS 2. Check also if the network supports this feature.
3. Establish PDP context with Conversational QoS.
EXPECTED RESULT:
PDPc with conversational QoS properly established.
TC-HSPAT-MOBIL- 33TU - Intra- PRECONDITIONS:

027a frequency HO There must be an appropriate number of 3G cells available on the same PLMN. The
RAB to be tested should be active, and available in all parts of the test route.
DESCRIPTION:
The DuT shall be engaged in voice call and data transfer (CELL_DCH State).
EXPECTED RESULT:
ADDITIONAL INFO:
TC-HSPAT-MOBIL- 3IC to 3IU - Intra- PRECONDITIONS:

020a frequency reselection There must be an appropriate number of 3G cells available on the same PLMN. The
DESCRIPTION:
The DuT shall perform a data transfer (CELL_DCH State), and it shall be started with
DuT being camped in a R99 cell, and then will handover to R6 cell.
With the active file download, the DuT shall move from one R99 cell to a HSPA cell
that belong to the same RNC.
Check intra-frequency.
EXPECTED RESULT:
ADDITIONAL INFO:
TC-HSPAT-MOBIL- 33IU - Intra-frequency PRECONDITIONS:

022a reselection There must be an appropriate number of 3G cells available on the same PLMN. The
DESCRIPTION:
The DuT shall transfer a file successfully.
With the active file download, move from one HSPA cell to another HSPA cell that
belong to the same RNC.
EXPECTED RESULT:
Check the following RRC messages:
- Check event 1a is triggered with the new SC to be added in the active set.
- Check event 1b is triggered with the SC to be removed from the active set.
- Check the SC to be set as primary cell in the active set is the one received with
better signal level. 1d event well triggered.
ADDITIONAL INFO:
With a logging tool, check the events sent in the signaling messages.
TC-HSPAT-MOBIL- 33IU - Inter-frequency PRECONDITIONS:

031a with Compressed There must be an appropriate number of 3G cells available on the same PLMN. The
Mode RAB to be tested should be active, and available in all parts of the test route.
DESCRIPTION:
The DuT shall do reselection in CELL_DCH (CS attached).
EXPECTED RESULT:
TC-HSPAT-MOBIL- 33IU - Handover from PRECONDITIONS:

032a DC-HSDPA coverage There must be an appropriate number of 3G cells available on the same PLMN. The
cells to one HSPA cell RAB to be tested should be active, and available in all parts of the test route.
The DuT should be able to support Dual Cell HSDPA (DC-HSDPA).
DESCRIPTION:
With the active file download, move from DC-HSDPA coverage cells to one HSPA
cell.
It is a PS Data test, the DuT should be actively transmitting data. The data rate shall
This scenario is designed to test handovers.
EXPECTED RESULT:
The DuT should be able to speed down its downlink throughput when it moves from
DC-HSDPA coverage cells to one HSPA cell.
ADDITIONAL INFO:
TC-HSPAT-MOBIL- 33IU - Handover from PRECONDITIONS:

035a one HSPA cell to DC- There must be an appropriate number of 3G cells available on the same PLMN. The
HSDPA coverage RAB to be tested should be active, and available in all parts of the test route.
cells The DuT should be able to support Dual Cell HSDPA (DC-HSDPA).
DESCRIPTION:
With the active file download, move from one HSPA cell to DC-HSDPA coverage
cells.
It is a PS Data test, the DuT should be actively transmitting data. The data rate shall
This scenario is designed to test handovers.
EXPECTED RESULT:
The DuT should be able to speed up its downlink throughput to 42 Mbit/s when it
moves to DC-HSDPA coverage cells.
ADDITIONAL INFO:
TC-HSPAT-PRFMC- Download and Upload PRECONDITIONS:

002a simultaneously The DuT is CS attached and PS attached on an EUL enabled cell in its 3G HPLMN
The DuT has a PDP context already active by means of a dial-up networking session
acting the DuT as a modem.
DESCRIPTION:
1. Verify that a dial-up networking session is already established.
2. Start an FTP download. Use an uncompressible file larger than 200Mbytes.
50Mbytes. Assure the permission to upload contents.
application.
EXPECTED RESULT:
The DuT shall be able to present average throughput values proportional to the EUL
capability of the device and the EUL uplink RAB enabled for the cell.
ADDITIONAL INFO:
configuration by the tester, then UDP protocol may be utilised to perform this test
case.
TC-HSPAT-PRFMC- FTP Upload 50 MB PRECONDITIONS:

003a The DuT is CS attached and PS attached on an EUL enabled cell in its 3G HPLMN
The DuT has a PDP context already active by means of a dial-up networking session
acting the DuT as a modem.
DESCRIPTION:
2. Start an FTP upload. Use an uncompressible file larger than 50Mbytes. Assure the
permission to upload contents.
3. Measure the upload throughput using a suitable application.
EXPECTED RESULT:
The DuT shall be able to present average throughput values proportional to the EUL
capability of the device and the EUL uplink RAB enabled for the cell.
ADDITIONAL INFO:
The TCP RX window size FTP server shall be set appropriately so that optimum
Uplink performance is achieved. If the TCP RX window size of the FTP server cannot
be set to an optimum configuration by the tester, then UDP protocol may be utilised
to perform this test case.
TC-HSPAT-STRES- FTP upload PRECONDITIONS:

001a The DuT is CS attached and PS attached on an EUL enabled 3G cell in its 3G
HPLMN and a PDP context active by means of a dial-up session.
DESCRIPTION:
2. Connect to a known FTP Server using an FTP client. Assure the permission to
upload contents.
3. Manage to upload a file.
EXPECTED RESULT:
The DuT shall be able to connect to the FTP server and successfully upload a file.
Use of an EUL bearer shall be verified by appropriate logging tools (where possible).
ADDITIONAL INFO:
The file size must be 150 MB.
TC-HSPAT-STRES- FTP download PRECONDITIONS:

002a The DuT is IMSI attached and PS attached on an HSDPA enabled 3G cell in its 3G
HPLMN and a PDP context active by means of a dial-up session.
DESCRIPTION:
2. Connect to a known FTP Server (e.g. ftp.3gpp.org ) using an FTP client or using
DOS command (ftp ftp.3gpp.org)
3. Manage to download a file.
EXPECTED RESULT:
The DuT shall be able to connect to the FTP server and successfully download a file.
Technologies Device Type Local/Regional

Browser Mobile handset;Free L
PASS
N/A
PASS
PASS
PASS
PASS
PASS
PASS
PASS
Browser Mobile L
handset;FWT;Free
PASS
MMS Mobile handset;Free L
N/A
PASS
PASS
MMS Mobile L
handset;FWT;Free
PASS
MMS Mobile L
handset;FWT;Free
PASS
MMS Mobile L
handset;FWT;Free
PASS
MMS Mobile L
handset;FWT;Free
PASS
PASS
PASS
PASS
MMS Mobile L
handset;FWT;Free
PASS
MMS Mobile L
handset;FWT;Free
PASS
PASS
PASS
N/A
PASS
N/A
N/A
PASS
MMS Mobile L
handset;FWT;Free
PASS
MMS Mobile L
handset;FWT;Free
PASS
MMS Mobile L
handset;FWT;Free
PASS
MMS Mobile L
handset;FWT;Free
PASS
MMS Mobile L
handset;FWT;Free
PASS
SMS M2M-with-MMI;Mobile L
handset;Free
PASS
handset;Free
PASS
SMS Mobile L
handset;DataCard-
USBmodem;Laptop-
UMPC-
Netbook;FWT;Free
PASS
SMS Mobile L
handset;DataCard-
USBmodem;Laptop-
UMPC-
Netbook;FWT;Free
PASS
SMS Mobile L
handset;DataCard-
USBmodem;Laptop-
UMPC-
Netbook;FWT;Free
N/A
SMS Mobile handset;Free L
N/A
SMS Mobile L
handset;DataCard-
USBmodem;Laptop-
UMPC-
Netbook;FWT;Free
N/A
SMS Mobile L
handset;DataCard-
USBmodem;Laptop-
UMPC-Netbook;Mobile-
Routers;M2M-with-
MMI;FWT;Free
N/A
SMS Mobile L
handset;DataCard-
USBmodem;Laptop-
Routers;M2M-with-
MMI;FWT;Free N/A
SMS Mobile handset;Mobile- L

Routers;M2M-with-
MMI;Free
N/A
SMS Mobile handset;Mobile- L

Routers;M2M-with-
MMI;Free
N/A
SMS Mobile L
handset;DataCard-
USBmodem;Laptop-
UMPC-
Netbook;FWT;Free N/A
SMS Mobile L
handset;DataCard-
USBmodem;Laptop-
UMPC-
Netbook;FWT;Free
PASS
handset;Free
PASS
Usability Mobile handset;Free L
PASS
GSM;Voice Mobile L
handset;DataCard-
USBmodem;Laptop-
UMPC-Netbook;Internal
Mobile Broadband
Module;Mobile- PASS
Routers;Chipset;M2M-
with-MMI;M2M-without-
MMI;FWT;Free
GSM;Voice Mobile handset;Laptop- L

Routers;FWT;Free
PASS
GSM;Voice DataCard- L
USBmodem;Laptop-
UMPC-Netbook;M2M-
MMI;Mobile
handset;Chipset;Internal
Mobile Broadband
Module;FWT;Mobile-
Routers;Free
PASS

Routers;FWT;Free
PASS

Routers;FWT;Free
PASS

UMPC-
Netbook;FWT;Free
PASS
GSM;Voice Free;FWT;Mobile L
handset
PASS
USBmodem;Laptop-
UMPC-Netbook;M2M-
MMI;Mobile
Mobile Broadband
Module;FWT;Mobile- N/A
Routers;Free
USBmodem;Laptop-
UMPC-Netbook;M2M-
MMI;Mobile
handset;Chipset;Internal N/A
Mobile Broadband
Module;FWT;Mobile-
Routers;Free
USBmodem;Laptop-
UMPC-Netbook;M2M-
MMI;Mobile
Mobile Broadband
Routers;Free
USBmodem;Laptop-
UMPC-Netbook;M2M-
MMI;Mobile
Mobile Broadband
Module;FWT;Mobile-
Routers;Free
USBmodem;Laptop-
UMPC-Netbook;M2M-
MMI;Mobile
Mobile Broadband
Routers;Free
GSM;Voice Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile-
MMI;FWT;Free
N/A

UMPC-
Netbook;FWT;Free
PASS

UMPC-
Netbook;FWT;Free
N/A

UMPC-
Netbook;FWT;Free
N/A

UMPC-
Netbook;FWT;Free
N/A
USBmodem;Laptop-
UMPC-Netbook;M2M-
MMI;Mobile
Mobile Broadband
Module;FWT;Mobile
desktop phone;Mobile-
Routers;Free
N/A

UMPC-
Netbook;FWT;Free
PASS

UMPC-
Netbook;FWT;Free
PASS

UMPC-
Netbook;FWT;Free
PASS
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile- PASS
MMI;FWT;Free
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Chipset;M2M-
MMI;FWT;Free N/A
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile-
Routers;Chipset;M2M- N/A
MMI;FWT;Free
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Chipset;M2M-
MMI;FWT;Free
N/A
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile- N/A
MMI;FWT;Free
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband N/A
Module;Chipset;M2M-
MMI;FWT;Free
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Chipset;M2M-
MMI;FWT;Free
N/A
HSDPA Mobile handset;Mobile- L

MMI;FWT;Free
N/A

MMI;FWT;Free
N/A
HSDPA DataCard- L
USBmodem;Laptop-
UMPC-Netbook;M2M-
MMI;Mobile
Mobile Broadband
Module;FWT;Mobile-
Routers;Free
N/A

MMI;FWT;Free
N/A

MMI;FWT;Free
N/A

MMI;FWT;Free
N/A
HSDPA DataCard- L
USBmodem;Laptop-
UMPC-Netbook;M2M-
MMI;Mobile
Mobile Broadband
Module;FWT;Mobile-
Routers;Free
N/A
HSDPA DataCard- L
USBmodem;Laptop-
UMPC-Netbook;M2M-
MMI;Mobile
Mobile Broadband
Module;FWT;Mobile-
Routers;Free
N/A
HSDPA DataCard- L
USBmodem;Laptop-
UMPC-Netbook;M2M-
MMI;Mobile
Mobile Broadband
Module;FWT;Mobile-
Routers;Free
N/A
HSDPA Mobile handset;Laptop- L

MMI;FWT;Free
N/A
HSDPA Mobile handset;Laptop- L

Routers;Free
N/A

MMI;FWT;Free
N/A

MMI;FWT;Free
N/A
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Chipset;M2M-
MMI;FWT;Free
N/A
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Chipset;M2M-
MMI;FWT;Free
N/A
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Chipset;M2M-
MMI;FWT;Free
N/A
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Chipset;M2M-
MMI;FWT;Free
N/A
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Chipset;M2M-
MMI;FWT;Free
N/A
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Chipset;M2M-
MMI;FWT;Free
N/A
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Chipset;M2M-
MMI;FWT;Free
N/A
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Chipset;M2M-
MMI;FWT;Free
N/A
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile-
MMI;FWT;Free
N/A
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile-
MMI;FWT;Free
N/A
HSDPA DataCard- L
USBmodem;Laptop-
UMPC-Netbook;M2M-
MMI;Mobile
Mobile Broadband
Module;FWT;Mobile-
Routers;Free
N/A
HSDPA DataCard- L
USBmodem;Laptop-
UMPC-Netbook;M2M-
MMI;Mobile
Mobile Broadband
Module;FWT;Mobile-
Routers;Free
N/A
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile-
MMI;FWT;Free
N/A
HSDPA DataCard- L
USBmodem;Laptop-
UMPC-Netbook;M2M-
MMI;Mobile
Mobile Broadband
Module;FWT;Mobile-
Routers;Free
N/A
HSDPA DataCard- L
USBmodem;Laptop-
UMPC-Netbook;M2M-
MMI;Mobile
Mobile Broadband
Module;FWT;Mobile-
Routers;Free
N/A
HSDPA DataCard- L
USBmodem;Laptop-
UMPC-Netbook;M2M-
MMI;Mobile
Mobile Broadband
Module;FWT;Mobile-
Routers;Free
N/A
HSDPA DataCard- L
USBmodem;Laptop-
UMPC-Netbook;M2M-
MMI;Mobile
Mobile Broadband
Module;FWT;Mobile-
Routers;Free
N/A
HSDPA DataCard- L
USBmodem;Laptop-
UMPC-Netbook;M2M-
MMI;Mobile
Mobile Broadband
Module;FWT;Mobile-
Routers;Free
N/A
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile-
MMI;FWT;Free
N/A
HSDPA DataCard- L
USBmodem;Laptop-
UMPC-Netbook;M2M-
MMI;Mobile
Mobile Broadband
Module;FWT;Mobile-
Routers;Free
N/A
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile-
MMI;Free
N/A
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile-
MMI;Free
N/A
HSDPA DataCard- L
USBmodem;Laptop-
UMPC-Netbook;M2M-
MMI;Mobile
Mobile Broadband
Module;FWT;Mobile-
Routers;Free
N/A
HSDPA DataCard- L
USBmodem;Laptop-
UMPC-Netbook;M2M-
MMI;Mobile
Mobile Broadband
Module;FWT;Mobile-
Routers;Free
N/A
HSDPA DataCard- L
USBmodem;Laptop-
UMPC-Netbook;M2M-
MMI;Mobile
Mobile Broadband
Module;FWT;Mobile-
Routers;Free
N/A
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile-
MMI;FWT;Free
N/A
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Chipset;M2M-
MMI;FWT;Free
N/A
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Chipset;M2M-
MMI;FWT;Free
N/A
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Chipset;M2M-
MMI;FWT;Free
N/A
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Chipset;M2M-
MMI;FWT;Free
N/A
HSDPA DataCard- L
USBmodem;Laptop-
UMPC-Netbook;M2M-
MMI;Mobile
Mobile Broadband
Module;FWT;Mobile-
Routers;Free
N/A
HSDPA Mobile handset;Free L
N/A
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile-
MMI;FWT;Free
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile-
MMI;FWT;Free
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile-
MMI;FWT;Free
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile-
MMI;FWT;Free
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile-
MMI;FWT;Free
PASS
HSDPA DataCard- L
USBmodem;Laptop-
UMPC-Netbook;M2M-
MMI;Mobile
Mobile Broadband
Module;FWT;Mobile-
Routers;Free
HSDPA DataCard- L
USBmodem;Laptop-
UMPC-Netbook;M2M-
MMI;Mobile
handset;Chipset;Internal PASS
Mobile Broadband
Module;FWT;Mobile-
Routers;Free
HSDPA Mobile L
handset;DataCard-
USBmodem;Free
N/A
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile- N/A
MMI;FWT;Free
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile- N/A
MMI;FWT;Free
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile- N/A
MMI;FWT;Free
HSDPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile- N/A
MMI;FWT;Free
HSDPA;HSUPA Mobile handset;Mobile- L

MMI;FWT;Free
N/A
HSDPA;HSUPA Mobile L
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile-
MMI;FWT;Free
N/A
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile-
MMI;FWT;Free
N/A
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile-
MMI;FWT;Free
N/A
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile-
MMI;FWT;Free
N/A
HSDPA;HSUPA Chipset;DataCard- L
USBmodem;Free;FWT;I
nternal Mobile
Broadband
Module;Laptop-UMPC-
Netbook;M2M-with-
MMI;M2M-without-
MMI;Mobile
handset;Mobile-Routers
N/A
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile-
MMI;FWT;Free
PASS
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile-
MMI;FWT;Free
PASS
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile-
with-MMI;M2M-without- PASS
MMI;FWT;Free
handset;DataCard-
USBmodem;Laptop-
Mobile Broadband
Module;Mobile-
Routers;Chipset;M2M- PASS
MMI;FWT;Free

Protocolo Field Test Claro

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Protocolo Field Test Claro

Caricato da

Copyright:

Formati disponibili

3E8430LBI - Microsoft

Test Code Test Name Description

TC-BRWSR-ASYNC- Receiving a videocall DESCRIPTION:

TC-BRWSR-ASYNC- Receiving a short DESCRIPTION:

TC-BRWSR-ASYNC- Receiving a DESCRIPTION:

TC-BRWSR-ASYNC- Receiving of SMS DESCRIPTION:

TC-BRWSR-BASOP- Comparing and rating DESCRIPTION:

TC-BRWSR-BASOP- Browsing and DESCRIPTION:

TC-BRWSR-BASOP- Time to connect to the DESCRIPTION:

TC-BRWSR- Compatibility with DESCRIPTION:

TC-BRWSR- HTTPS connection DESCRIPTION:

TC-MMSTC-COMPT- Subject field with 40 PRECONDITIONS:

TC-MMSTC-COMPT- Send and receive PRECONDITIONS:

TC-MMSTC-COMPT- Send and receive PRECONDITIONS:

TC-MMSTC-COMPT- Recipient name PRECONDITIONS:

TC-MMSTC-COMPT- Message with text, PRECONDITIONS:

TC-MMSTC-COMPT- Supported slides in a PRECONDITIONS:

TC-MMSTC-COMPT- USIM addresses PRECONDITIONS:

TC-MMSTC-MMITC- Deleting of an MM PRECONDITIONS:

TC-MMSTC-MMITC- Deleting of all MMs in PRECONDITIONS:

TC-MMSTC-MMITC- Deleting of all MMs in PRECONDITIONS:

TC-MMSTC-RECVN- Reception of audio DESCRIPTION:

TC-MMSTC-RECVN- Behaviors upon PRECONDITIONS:

*Automatic retrieval description for GPRS device class A

*Automatic retrieval description for GPRS device class B

*Automatic retrieval description for UMTS device

* Recommended Retrieval Mode M In case that the MMS Notification recommends

The following steps will be carried out for class A and B:

TC-MMSTC-RECVN- MMS during voice call PRECONDITIONS:

TC-MMSTC-RECVN- Reception of an MM DESCRIPTION:

TC-MMSTC-RECVN- Reception of an MM DESCRIPTION:

TC-MMSTC-RECVN- Reception of an MM DESCRIPTION:

TC-MMSTC-RECVN- Reception of an MM DESCRIPTION:

TC-MMSTC-RECVN- Reception of an MM DESCRIPTION:

TC-MMSTC-SENDG- Sending Attachment PRECONDITIONS:

TC-MMSTC-SENDG- Text with US-ASCII PRECONDITIONS:

TC-MMSTC-SENDG- Text with special PRECONDITIONS:

TC-MMSTC-SENDG- Sending a MM to an DESCRIPTION:

TC-MMSTC-SENDG- Indicator of sending DESCRIPTION:

TC-MMSTC-FEATR- VIDEO H263 + AMR- PRECONDITIONS:

TC-SMSTC-CODTC- Terminated DESCRIPTION:

TC-SMSTC-CODTC- Input concatenated DESCRIPTION:

TC-SMSTC-MMITC- Terminated DESCRIPTION:

TC-SMSTC-MMITC- Substitution of sender DESCRIPTION:

TC-SMSTC-RCPTC- Message class 0 to 3 DESCRIPTION:

TC-SMSTC-RCPTC- Reception of SM DESCRIPTION:

TC-SMSTC-RCPTC- Message class 0 to 3 DESCRIPTION:

TC-SMSTC-RCPTC- Message class 0 to 3 DESCRIPTION:

TC-SMSTC-RCPTC- Reception of SM DESCRIPTION:

TC-SMSTC-RCPTC- Reception of SM type DESCRIPTION:

TC-SMSTC-RCPTC- Reception of SM type DESCRIPTION:

TC-SMSTC-RCPTC- SMS mobile DESCRIPTION:

TC-SMSTC-SNDTC- Input SM (160 DESCRIPTION:

TC-SMSTC-SNDTC- Minimum number of DESCRIPTION:

TC-USBLT-RGSTT- Sending a SM to a DESCRIPTION:

TC-GSMFT-BASOP- Mobile originated call DESCRIPTION:

TC-GSMFT-BASOP- Mobile originated DESCRIPTION:

TC-GSMFT-BASOP- Finishing of a call by a DESCRIPTION:

TC-GSMFT-BASOP- Voice Ciphering DESCRIPTION:

TC-GSMFT-BASOP- Voice mail DESCRIPTION:

TC-GSMFT-CLIRT- CLIR Test DESCRIPTION:

TC-GSMFT-CLIRT- CLIR Test - reception PRECONDITIONS:

TC-GSMFT-SUPPL- Barring all outgoing DESCRIPTION: