Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
  • H04W88/02—Terminal devices

Definitions

• the invention deals with updating of data stored in a file included in a data processing system.
• the present invention relates generally to handling roaming lists in a wireless communication system, and more specifically to updating a preferred roaming list PRL (Preferred Roaming List).
• PRL Preferred Roaming List
• this list is stored in a SIM (Subscriber Identity Module) card or a RUIM (Removable User Identity Module)
• SIM Subscriber Identity Module
• RUIM Removable User Identity Module
• a PRL is a list defined in the specifications [S0023] and [S0016] for CDMA (Code-Division Multiple Access). These two documents are incorporated by reference to the description. It allows the Operator to use the OTAPA/SP commands to update the over the air using a defined protocol [S0016]. The relevant files are described in the [S0023] specification.
• the PRL list is a list of information that resides in the memory of a smart card coupled to a mobile phone. This list is set by the network operator and stored in the SIM/RUIM card. It lists the frequency bands the phone can use in various parts of a country. This list can be updated by the home network operator by means of data download over the air (OTA).
• OTASP Over-the-Air Service Provisioning
• Over-the-Air Parameter Administration is a network initiated OTASP process of provisioning mobile phone operational parameters over the air interface.
• Over-the-Air Service Provisioning (OTA SP) is a process of provisioning mobile station operational parameters over the air interface. The mobile station can receive Preferred Roaming List parameters in one or more SSPR commands from the network. As the APDU buffer on a RUIM is today restricted to 255 bytes, a complete PRL update will be sent over many commands.
• a list PRL is stored in a temporary storage until reception of a "commit" command received from the server requesting the PRL list update.
• the server sends a 'Commit APDU'
• all the data stored in said temporary storage is copied into the file EF pr ⁇ file itself in a permanent memory.
• the process is very long due to limited resources in the smart card.
• the problem becomes worse as the size of the PRL increases.
• the size of a PRL update is about 500 bytes.
• the processor of the card is engaged in an update process for a long period of time. This is unacceptable in a GSM context as it is stated that each command should take no longer than 2 seconds in order to allow 'authentication' during a session.
• said data processing system comprises a second file Efmr stored in permanent memory, this file Efmr having the same structure as the first file Efprl, said second file storing data information updates received from the network, and in that when the first file Efprl has to be updated by said second file Efmr, the second file Efmr is renamed by the name of the first file (Efprl).
• a file EFmr as temporary storage provides a way to get consistent timing for PRL update operations regardless of the size of the PRL list.
• FIG. 1 is a block diagram view of the architecture of a computer system on which the solution can be applied.
• Figure 2 is an example of an OTAPA/SP sequence for PRL Update. Card and ME actions.
• Figure 1 illustrates a system SYS including a mobile phone ME coupled to a RUIM card CARD.
• the card CARD stores a list PRL.
• This example is not restrictive; the PRL list could be for example stored in the mobile phone ME.
• System SYS also comprises a server SERV. In our example, this server is the home network operator. PRL lists are loaded into the SIM card from this server.
• FIG. 2 is an example of a communication between said couple Mobile- Card and the server SERV.
• Reference COM means that PRL Update blocks are stored in EFmr file. This is updated as many times as required until the 'COMMIT' command.
• This PRL comprises a list of preferred telecom operators.
• This list is stored in a file EF pr ⁇ which can be updated.
• the structure of EF pri includes parameters blocks.
• parameters blocks are: -
• a file ID block defines the file name.
• a file ID is used to address or identify each specific file.
• this file ID includes two bytes.
• - Access conditions block defining access rights on Read command, Update command, Invalidate command, Rehabilitate command. The Access conditions are set for administrator use only.
• Such file Efprl includes other blocks, but for a better understanding of the invention, we have simplified in reducing the number of blocks and in using a vocabulary other than used in the above standards.
• this file is inaccessible by the user of the card.
• the only person allowed to use this file is the administrator ADM. This way, the file Efmr can't be modified. Obviously, this way to manage access conditions is not restrictive; any other way to manage access might be used.
• each parameter block is the following: - the file name is 6F30 - the access conditions are the following: ⁇ Read command can be used with a password CHV1 ⁇ And Update, Invalidate, Rehabilitate commands can be used by the administrator ADM. - The preferred operators are "TeleCom 1", “TeleCom2". In our example, we see that the user is allowed to use Read command and not the other commands. This example is not restrictive, any other access rights can be implemented function of the context. Let's suppose the operator wants to update the file EF pr ⁇ by a new one corresponding to the second file Efmr.
• the card also stores a second file Efmr.
• the operator downloads this file into the card CARD.
• the structure of this second file Efmr is the same as file EF pr ⁇ .
• This file includes the same parameter blocks as the file EF pr ⁇ but is located at a different place in memory and its content can be different from file EF pr
• the first and second files are stored in the same permanent memory.
• the content of each parameter block is the following: - the file name is FF30 - the access conditions are the following: ⁇ Read, Update, Invalidate, Rehabilitate commands can be used by the administrator ADM; - The preferred operators are: "Complus” and "operaT”.
• Step l In a first step, referring to figure 2 and more particularly to reference COM, the operator sends a message (or a plurality of commands as shown on figure 2) including a new list of partners. Step 2 The mobile receives this message and stores the new list in said second file Efmr. Step 3 After reception and storage of the list of partners in Efmr, referring to figure 2, the operator server sends an update command. In our example, this command corresponds to the "commit" command. Step 4 When receiving this "commit" command, a program is therefore activated. The program renames the files as follows: - Rename the file Efmr by EFpri.
• the second file EFmr becomes the current file EFpri by internally modifying the file header ID to EFpri.
• Old EFpri Becoming the new file dedicated for the updates.
• the file previously known as EFpri is for example renamed to a temporary File ID and used for storing future updates.
• the Access conditions are also swapped between the 2 files.
• the new file EF pr ⁇ is used as preferred operator list PRL for communicating with the network.
• this procedure will be encapsulated in a transaction, allowing backup of previous data in case of unsuccessful completion of update.
• file identifiers FF30, 6F30
• the file ID can be of any value that does not affect normal functioning of the RUIM or Card.
• data information stored in the second file Efmr is not deleted.
• the server could reuse this data information if updates are those stored in this file.
• the operator would only have to send a command including a "commit" command without data information updates. This avoids the server to download a new time data information updates over the air.
• Each file could be used in target regions where the operator has agreement with a respective partners list.
• Storing large PRL doesn't affect performance for RUIM as the update just consists in renaming a file.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Priority Applications (1)

Applications Claiming Priority (3)

Publications (1)

Family

ID=34778229

Family Applications (2)

Family Applications Before (1)

Country Status (4)

Families Citing this family (13)

Family Cites Families (6)

• 2004
  • 2004-01-14 EP EP04290101A patent/EP1583381A1/de not_active Withdrawn
• 2005
  • 2005-01-12 WO PCT/IB2005/000048 patent/WO2005069660A1/en active Application Filing
  • 2005-01-12 CN CN2005800045618A patent/CN1918932B/zh active Active
  • 2005-01-12 BR BRPI0506813-4A patent/BRPI0506813B1/pt active IP Right Grant
  • 2005-01-12 EP EP05702218A patent/EP1733580A1/de not_active Withdrawn

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events