WO2009083027A1

WO2009083027A1 - Method and system for managing data in a memory

Info

Publication number: WO2009083027A1
Application number: PCT/EP2007/064579
Authority: WO
Inventors: Radha Krishna Atukula; Dominic Lenz
Original assignee: Nokia Corporation
Priority date: 2007-12-27
Filing date: 2007-12-27
Publication date: 2009-07-09

Abstract

A method of writing data to a memory comprises receiving a first message having a first data part; writing the first message to the memory; and writing location information for a subsequent message to a location in said memory.

Description

Method and system for managing data in a memory

Field of the Invention

The present invention relates to managing data in a memory and in particular, but not limited to writing and reading messages of unknown and arbitrary size in a memory buffer.

Background of the Invention

Known communication environments can be quite varied. For example, within a single device or entity, there may be communications between different functionalities or nodes within that device. Alternatively, two or more devices may be connected together and there may be communications between two or more of the devices . It is known to have two devices communicating with each other via one or more other devices such as in the context of a packet data network, a mobile communications network or the like.

It is known for the packet data network or the mobile communications network to provide communication between communicating devices using a layer protocol for interconnecting devices, components circuits or modules such as cellular telephones, handheld computers, digital cameras and multimedia devices .

An example of a protocol stack of layers is shown in Figure 1. The protocol stack may be in accord with the OSI SS7 model. In the arrangement shown in Figure 1, there is an application specific protocol layer LA. This is on top of the transport layer L4. The transport layer L4 is in turn on top of the network layer L3 which is on top of the data link layer L2. This is in turn on the physical layer Ll.

Typical communication processes exchange messages between two peer entities or peer processes. A message could be any type of data of any size. A message might be divided in a plurality of segments. In some circumstances the messages size may not be more than a predetermined size and usually the receiving entities (e.g. a receiver) or processes allocate a buffer of a size equal to or larger than the maximum predetermined size. In this way no messages exceed the size of the buffer.

In some cases the rate of consumption of messages at the receiving entity or process is almost equal to the rate of issuance of messages from a sending entity (e.g. a transmitter) or process. If the message size also is small compared to the maximum allowed message size, then the allocating a buffer having a maximum message size substantially greater than the typical message size reduces the efficiency of buffer utilization.

Alternatively, the sending entity or process includes the size of the message in the header of the message which is used for allocating buffer space. This helps maintain a linked list of messages in a separate memory buffer, where the size or length information received in the header of the message is used to point to the start of the next message

Two buffers may be provided to process a message when its size and / or length is not communicated before or together with the message. For example a first buffer is used to store received messages and a second buffer is used for storing information for locating the start of the messages in the first buffer. The start of the messages may be located with an address or with an operation such as adding an offset to an address. The information for locating the start of the messages is not part of the message and may be considered an overhead . A problem arises when the number of messages increases and the messages have a small size. This is because the second buffer, storing information for locating the start of the messages in the first buffer, may become bigger than the first buffer. In other words, the overall message overhead is larger than the useful data in the messages .

Summary

It is an aim of some embodiments of the invention to address at least one of the disadvantages or problems discussed above.

Accordingly in a first aspect the present invention provides a method of writing data to a memory comprising: receiving a first message having a first data part; writing the first message to the memory; and writing location information for a subsequent message to a location in said memory.

That allows the usage of a buffer having a size less than an allowed maximum message size predetermined by a system or protocol. Indeed, a message of any arbitrary size can be handled in a buffer of limited size. Advantageously this means that in some embodiments the present invention can receive and handle messages which are greater in size than the buffer size. Furthermore, the length or size of the message is not required to be transmitted before or along with the message.

Information regarding the location of the next subsequent message is derived from the received message and this location information is stored as metadata in the memory buffer. This means a separate, dedicated memory buffer for storing location information and provide a linked list may not be necessary.

Preferably the method further comprises the step of deriving the location information after the first data part is received.

The location information may be considered as an overhead, which may be a fixed number of bytes that a receiver entity requires for managing messages, in the memory buffer.

Preferably the location information is written in a location in the memory adjacent to the first message.

Preferably the method further comprises updating the location information.

Preferably the method further comprises validating the location information.

Preferably the method further comprises deriving validation information associated with the location information. Preferably the validation information is written in a location in the memory adjacent to the first message or the location information.

The validation information and the location information may be stored in a second data part. The second data part may be located next to the first part of the message once the message has been received. Alternatively the second data part may be located remote from the first data part.

Preferably the step of validating is carried out after receiving the end of the first message.

Preferably the end of message is indicated by an end of message flag.

Preferably the location information is an available location in the memory buffer after the end of first message.

Preferably the method further comprises the step of writing the subsequent message starting at the location information.

Preferably the step of writing the subsequent message is carried out if the location information is valid.

Preferably the memory is a memory buffer.

Preferably the location information and the validation information are protected when receiving the message. In this way, the location information and the validation information are read-only during the process of receiving the message. That is, the location information and the validation information are not over-written and the location information and the validation information are preserved when data is written to the memory buffer.

Preferably protection information indicates whether the location information and the validation information are protected. In some embodiments the protection information may be a flag indicating that location information and the validation information are protected. Alternatively, the protection information may be indicated using multiple flags and / or variables. That is, the protected status of the location information and the validation information may be dependent on the variables and / or flags changed in multiple, concurrent processes (e.g. write and read process) .

Preferably protection information indicates whether the location information and the validation information are protected.

Preferably the location information and the validation information are not protected if the location information is valid.

Preferably the step of updating also updates whether the location information and the validation information are protected or not.

Preferably the memory buffer is cyclical or ring memory. This means that data being written to the memory buffer at the end of the memory buffer may wrap from the end of the buffer to the start of the buffer if the write process runs out of space. Preferably the message is one message segment or a plurality of message segments . A message received, at the memory buffer may be an individual message or may be one part of a message split into multiple parts.

Preferably the step of writing is suspended if the memory buffer is full.

Preferably a write pointer progress is used for the memory buffer to indicate the next memory block to be written.

According to a second aspect of the present invention there is a method of managing data in a memory comprising: receiving a first message having a first data part ; writing the first message to the memory; and writing location information for a subsequent message to a location in said memory; and reading the data from the memory.

Preferably a read pointer progresses through the memory buffer and indicates the next memory block to be read.

Preferably the step of reading is suspended if a blocking condition indicates that unread blocks of the memory buffer are unavailable to be read.

Preferably the blocking condition indicates that unread blocks are available if the location information is read. Preferably the steps of writing and reading are concurrent .

According to a third aspect of the present invention there is a memory managing unit comprising: a data processing unit; and a memory,- wherein the data processing unit is arranged to: receiving a first message having a first data part; writing the first message to the memory; and writing location information for a subsequent message to a location in said memory.

According to a fourth aspect of the present invention there is an apparatus in a communication network having: an interface for receiving messages from the communication network; a data processing unit configured to receive messages from the interface; and a memory; wherein the data processing unit is arranged to: receive a first message having a first data part; write the first message to the memory; and write location information for a subsequent message to a location in said memory.

According to a fifth aspect there is a computer program comprising program code means adapted to perform the following steps : receiving a first message having a first data part; writing the first message to the memory; and writing location information for a subsequent message to a location in said memory.

According to a sixth aspect of the present invention there is an apparatus in a communication network having: an interface means for receiving messages from the communication network; a data processing means configured to receive messages from the interface; and a memory means,- wherein the data processing means is arranged to: receive a first message having a first data part ; write the first message to the memory; and write location information for a subsequent message to a location in said memory.

Brief description of the drawings

For a better understanding of the present invention and as to how the same may be carried into effect, reference will now be made by way of example only to the accompanying drawings in which:

Figure 1 illustrates an example of a protocol stack of layers .

Figure 2 illustrates a flowchart for a buffer writing process according to an embodiment of the present invention.

Figure 3 illustrates a flowchart for a buffer reading process according to an embodiment of the present invention. Figures 4a, 4b, 4c illustrate a schematic representation of the memory buffer reading and writing process at times tl, t2 , t3 according to an embodiment of the present invention.

Figures 5a, 5b, 5c illustrate a schematic representation of the memory buffer reading and writing process at times t4, t5, t6 according to an embodiment of the present invention.

Figures 6a, 6b, 6c illustrate a schematic representation of the memory buffer reading and writing process at times t7, t8, t9 according to an embodiment of the present invention.

Figures 7a, 7b, 7c illustrate a schematic representation of the memory buffer reading and writing process at times tlO, til, tl2 according to an embodiment of the present invention.

Figure 8 illustrates a mobile device according to an embodiment of the present invention.

Detailed description of embodiments of the Invention

The present invention is described herein with reference to particular illustrative embodiments. However, such embodiments are presented for the purposes of illustrating the present invention, and does not limit the scope thereof .

Figure 8 discloses a mobile device 1 according to an embodiment of the present invention. Figure 8 is exemplary of a communicating device and is also applicable to other interconnecting devices, such components circuits or modules in cellular telephones, handheld computers, digital cameras, multimedia devices and other similar devices.

A user may control the operation of the mobile device 1 by means of a suitable user interface such as key pad 2, voice commands, touch sensitive screen or pad, combinations thereof or the like. A display 5, a speaker and a microphone are also typically provided. Furthermore, a mobile device may comprise appropriate connectors (either wired or wireless) to other devices and/or for connecting external accessories, for example hands-free equipment, thereto.

The mobile device 1 is typically provided with at least one data processing entity 3 and at least one storage device 4 for use in tasks it is designed to perform. The data processing and storage entities can be provided on an appropriate circuit board and / or in chipsets. This feature is denoted by reference 6. A memory buffer 9 is connected between the data processing entity 3 and storage device 4. The mobile device transmits and receives data to and from a communication network using radio part 7.

The data processing unit 3 performs the memory management operations with respect to the memory buffer 9. In an alternative embodiment the memory buffer can be located elsewhere in the system. For example could be on a memory card, random access memory unit, a hard disk, or any other suitable memory format. The memory management operations of the data processing unit 3 are described in further detail hereinafter.

In an alternative embodiment the data might be exchanged between functional modules like a display, a camera or a data processing unit of a device where the communication network might be based on a serial interconnect technology that might be based on source synchronous signalling or embedded-clock signalling. But any other wired or wireless communication technology may be applicable for the communication network.

Figures 2 and 3 disclose an embodiment of the present invention. In particular, figure 2 illustrates a flowchart of a memory buffer writing process according to an embodiment of the present invention. Figure 3 illustrates a flowchart for a memory buffer reading process according to an embodiment of the present invention. The read and write processes of the embodiment are concurrent and / or interrelated (e.g. sequentially or alternately) . Alternatively in another embodiment, the read and write processes are sequential and / or alternate .

The following definitions are used in illustrating and further explaining Figures 2 and 3.

The memory buffer uses following address locators or pointers to achieve: • MessageStartLocation: defines two fields:

1. the status information field which stores status information of the received message and; 2. the start location field which stores the location information of the start of the next message .

The status information field indicates whether the message is Finalized or NotFinalized. The location of the start of the next message in MessageStartLocation is valid if the message is Finalized. The location of the start of the next message is not valid unless the message is Finalized. This is a case where data continues to be received and the start location for a next message has not yet been finalised.

• TWritePtr : TWritePtr pointer points to the next location to be written. This is the address at which new data will be written by the receiving entity. TWritePtr pointer is updated after every write access .

• BlockingPtr : BlockingPtr is a pointer which forces the reading process by application/driver software to check MessageStartLocation of the current message whenever AppReadPtr pointer points to the same location in the memory buffer as BlockingPtr pointer. If this is the case, the application/driver software checks the MessageStartLocation field for the status information field. The application / driver software then updates its internal state for the next message accordingly. The application / driver software can only read data from the memory buffer up to and including this address. • CurMsgStartPtr : CurMsgStartPtr pointer is the start address of the current message being written in the memory buffer. That is, where MessageStartLocation field is located. When a message is bigger than the memory buffer size, then the TWritePtr pointer reaches and crosses the CurMsgStartPtr pointer. This means that the TWritePtr pointer points to the same location and then subsequently points to a next location in the memory buffer. If the TWritePtr pointer reaches the CurMsgStartPtr pointer, then the TWritePtr pointer should be updated appropriately to a location where data is allowed to be written. This protects the location information from being overwritten. The CurMsgStartPtr pointer is updated on reception of end of the current message. In this way the MessageStartLocation fields are protected during reception of related message information. • AppReadPtr : AppReadPtr pointer points to the next location to be read by the application/driver software. The AppReadPtr pointer is updated after each read access . In other words , the AppReadPtr pointer points to an address where the application / driver software is going to read data from the memory buffer. • AppNextMsgAdr : AppNextMsgAdr is a pointer which points to the location where the next message starts. The application / driver software updates the AppNextMsgAdr pointer with the next message start location whenever the application / driver software reads the MessageStartLocation field having the Finalized status information. This is an application/driver software scratch pad area where the application/driver software stores the location of the start of the next message. • AppCurMsgStartPtr : AppCurMsgStartPtr is a pointer to the start address of the message that the application / driver software is currently reading from the memory buffer. The AppCurMsgStartPtr pointer points to MessageStartLocation field of the message .

Figures 2 and 3 also use the following definitions: • Buffer: The Buffer is the area of memory which holds data to be read by Application/Driver software and is written by the receiving entity. The term "Buffer" is synonymous with the previously used term "memory buffer" . • BufWidth: BufWidth is a parameter defining the width of the Buffer.

• BufStartAdr: BufStartAdr is a parameter defining the starting address of the Buffer.

• BufEndAdr : BufEndAdr is a parameter defining the ending address of the Buffer.

• BufLen: BufLen is a parameter defining the length of the Buffer. The BufLen parameter is calculated with the equation:

BufLen = BufEndAdr - BufStartAdr + 1 • CurMsgPtrLen: CurMsgPtrLen is a variable defining the number of locations needed to store the CurMsgStartPtr pointer in the buffer.

• AppCurMsgPtrLen : AppCurMsgPtrLen is a variable defining the number of bytes or alternatively defining the number of locations needed to store the AppCurMsgStartPtr pointer in the Buffer.

• MsgStatus: MsgStatus is a variable defining the status information (or condition) of a message. The MsgStatus variable is a field provided in the MessageStartLocation information. The MsgStatus variable may have the conditions "NotFinalized" or "Finalized" . The condition "NotFinalized" indicates the message is not finalized yet (i.e. message length is not known) and/or the start location of the next message is not valid. The condition "Finalized" indicates that the message is finalized and/or the start location of the next message is valid.

• Blocked: Blocked is a flag to indicate whether the BlockingPtr pointer is allowed to move and/or whether the AppReadPtr pointer has crossed the BlockingPtr pointer or not. * Move2CurMsg: Move2CurMsg is a flag that indicates whether the BlockingPtr pointer is permitted move to the latest message being written to the memory buffer or not.

• DecSize : DecSize is a parameter that is used to keep the distance, or number of memory locations between the BlockingPtr pointer and the TWritePtr pointer.

• IncSize : IncSize is a parameter defining the incremental value (e.g. the number of memory locations) by which the AppReadPtr pointer moves in the memory buffer in a particular iteration.

• MsgSeglnd: MsgSeglnd is a flag which indicates the arrival of a new message segment for the memory buffer write process.

• EndCurMsg : EndCurMsg is a flag which indicates whether the current message portion which is being read out from the memory buffer is the last portion of the message or not. EndCurMsg is a flag used in the read process.

• Index: Index is a counter for counting over a series of iterative steps. • BufFull: BufFull is a flag which indicates whether the memory buffer is full. That means no further data can be stored.

• MsgEnd: MsgEnd is a flag which indicates whether the segment of the message is the last segment of the message or not. MsgEnd is a flag used in the write process .

Figures 2 and 3 further disclose the following functions and routines:

• GetMsgSegment (Data, DataLen, MsgEnd): GetMsgSegment is a procedure to get a portion of data ("Data") of a certain length ("DataLen") of a received message segment, the received message being the last segment of a message or not ( "MsgEnd" ) . A segment of a message is a part of a message which is transmitted and received in separate and different parts from other parts of the same message.

• WrapInc(Ptr, N) : Wraplnc is a routine to move a pointer to a new location. It returns the result of BufStartAdr + (Ptr - BufStartAdr + N) % BufLen (whereby "%" indicates a modulo operation)

• WrapDec(Ptr, N) : WrapDec is a routine to move a pointer to a new location. It returns the result of BufStartAdr + {Ptr + BufLen - BufStartAdr - N) % BufLen whereby ^ΛΛ%" indicates a modulo operation)

• DataCopy (DestAdr, Data2Cpy, CpyLen) : DataCopy is a routine that copies data "Data2Cpy" (e.g. data to be copied) of length "CpyLen" (e.g. the length of the data to be copied) into the variable "DestAdr" (updating the "DestAdr" pointer value) .

• PtrCopy (DestPtr, SrcPtr, CpyLen) : PtrCopy is a routine to copy content of variable "SrcPtr" into the "DestPtr" location (e.g. the location at the destination pointer) of "CpyLen" length {e.g. the length of the data to be copied) .

• Buffer [Ptr] = data: is an assignment which writes data ("data") to the memory buffer at a location "Ptr" .

• Write2Memory (data) : is a routine which writes data

("data") read from the memory buffer to a separate memory area.

• data = Buffer [Ptr] : is an assignment which read data ("data") from the memory buffer at a location "Ptr".

BlockingPtr, TWritePtr, CurMsgStartPtr, AppReadPtr, AppCurMsgStartPtr, AppNextMsgAdr pointers have widths which are sufficient to access any location within BufLen (e.g. the length of the memory buffer) .

Figures 4a to 7c illustrate the steps of the memory management operation in accordance with the present invention at different times (tl to tl2) . In particular, Figures 4a to Ic show an exemplary scenario whereby two short messages and one long Message are received, written to the memory buffer by the write process (shown in Figure 2) and read out by the read process (shown in Figure 3) .

The embodiment illustrated in Figures 4a to 7c has a memory buffer 9 with the following parameters: • BufWidth = 16bit

• BufStartAdr = 1024

• BufEndAdr = 65535

• BufLen = 65535 - 1024 + 1 = 64512 It should be appreciated that these values are by way of example only and the memory buffer can have any other suitable parameters .

Figure 4a shows a schematic representation of the memory buffer at time tl . Figure 4a shows a time just after initialization. The write process is started at step 200 as depicted by Fig. 2. The memory buffer 9 {see Fig. 8) initializes and prepares to receive a message and write it into the memory buffer 9 by initialising parameters, flags and fields as set out in step 202 (e.g. CurMsgStartPtr, BlockingPtr, TWritePtr = BufStartAdr, MsgStatus = NotFinalized, Index = 0, Move2CurMsg = false, Blocked = false, DecSize=l) .

In the following step 228 the locations 1024 and 1025 of the memory buffer 9 are initialized with the current MessageStartLocation field. The MessageStartLoctaion contains the message status field (e.g. NotFinalized) and the start location field of the next message. The start location of the next message is not known yet and therefore set to the start of the current message.

The CurMsgStrtPtr pointer and the BlockingPtr pointer are initialised in step 202 such that their location is the BufStartAdr as shown in Figure 4a.

The TWritePtr pointer has advanced to the location to which the first portion of a new message will be written.

The read process starts at step 300 as depicted by Fig. 3. The read process initialises at step 302 and defines various parameters of the read process. The AppNextMsgAdr pointer and the AppCurMεgStartPtr pointer are set to BufStartAdr (e.g. 1024) and the AppReadPtr pointer is set to BufEndAdr (e.g. 65535) . This is also shown in Figure 4a. However, although the read process has initialised, the read process has not started yet at time tl.

Figure 4b shows a schematic representation of the memory buffer at time t2. Figure 4b shows the status of the memory buffer 9 after receiving the beginning of MsgO . The start of a new message MsgO has been received (Msg0[0] ..MsgO [2]) and has been written to the memory buffer. The segment of data, in this case the entire of (MsgO [0] ..MsgO [2] ) is obtained using the GetMsgSegment routine as shown in step 204.

The TWritePtr pointer and the BlockingPtr pointer advance through the memory buffer whilst the Index counter is less than the length of the message segment (e.g. DataLen) . This stage is shown in step 206. The data is written at the location in the memory corresponding to the TWritePtr pointer (step 208) and the TWritePtr and BlockingPtr pointers then advance as shown in step 220, 232. The read process has just started at time t2 , due to that the AppReadPtr pointer has advanced to BufStartAdr as shown in step 304.

Figure 4c shows a schematic representation of the memory buffer at time t3. Figure 4c shows the status of the memory buffer after receiving the end of MsgO. As the end of the first message (MsgO) has been received the MsgEnd flag is set to "true" as shown in step 210. Since the MsgEnd flag is set to "true" , and the TWritePtr pointer has advanced one position beyond the first message 7 064579

(MsgO) , the TWritePtr pointer points to the position of the next message .

The MessageStartLocation fields are then updated {e.g. at location 1024 "NotFinalized" is updated to "Finalized" and at location 1025 "1024" is updated to "1031"). This is shown in step 212.

The CurMsgStrtPtr pointer pointing to the start of the next message is updated and subsequently points to location 1031 (e.g. the location of the CurMsgStrtPtr pointer is set to the location of the TWritePtr pointer} as shown in step 214.

The BlockingPtr is set to the last entry of the current Message and the Blocked flag has been set to "true" to prevent movement of the BlockingPtr. This is shown in step 216. The BlockingPtr does not move as long as the MessageStartLocation has not been read by the read process. For example, if the Blocked flag is set to

"true" , then the BlockingPtr pointer does not advance in the memory buffer because steps 218 and 220 are not available .

The read process has started at time t3 and the

AppReadPtr pointer proceeds to the start of the first message at location 1026. The first entry of the first message (MSgO[O]) is read. This is shown at step 306.

Figure 5a shows a schematic representation of the memory buffer at time t4. Figure 5a shows the status of the memory buffer after initialization and preparation to receive a new message but before receiving the new message . The MessageStartLocation fields (locations 1031 and 1032) are initialized with the current Message status ("NotFinalized" ) and the start location of the next message, which is not known yet and therefore set to the start of the current message ("1031"). This is shown in step 228.

Decision block 230 tests that the TWritePtr pointer is at the same location in the memory buffer 9 as the

CurMsgStartPtr pointer and therefore the location of the TWritePtr pointer is moved forward as shown in step 232. In this way the TWritePtr pointer skips over the MessageStartLocation fields to the next portion of the memory buffer where the first portion of the new message will be written.

The read process has continued reading MsgO [3] and goes from block 328 to decision block 308. At this point, as the AppReadPtr pointer is not at the same position of

BlockingPtr pointer, so AppReadPtr pointer is advanced to next location. Now, the AppReadPtr pointer is at the same position as BlockingPtr pointer at decision 310, stops normal data reading and checking (e.g. decision blocks 320, 324) of the MsgStatus condition and the start location field, the AppCurMsgStartPtr pointer is referencing to. While executing 312 sets Blocked flag to false and reads the status of the current message pointed by AppCurMsgStartPtr pointer. Since the MsgO is Finalized it updates AppNextMsgAdr pointer to the next message start location {"1031"). After that executes step 306 reading data of MsgO [4] , checks for decision block 314. The decision block 314 tests that whether the location of the AppNextMsgAdr is equal to the position after the AppReadPtr pointer and that the AppCurMsgStartPtr pointer is not equal to the position after the AppReadPtr pointer and sets the EndCurMsg flag to "true" in step 316. If not, the EndCurMsg flag is set to "false" in step 318. The read process advances to decision block 308.

Decision block 308 tests that the AppReadPtr pointer is at the same position as the BlockingPtr pointer. The read process is paused until the write process changes the value of the Blocked flag and allows the BlockingPtr to proceed.

Figure 5b shows a schematic representation of the memory buffer at time t5. Figure 5b shows the status of the memory buffer 9 after receiving the end of Msgl .

A complete new message has been received (Msgl [O]... Msgl [2]) and has been written to the memory buffer according to the writing process as outlined above and the TWritePtr pointer and the BlockingPtr pointer have advanced accordingly.

The MessageStartLocation fields (at locations 1031 and 1032) have been updated (Finalized, 1036) according to step 228. The CurMsgStrtPtr pointer location is updated and points to the start of the next expected Message at location 1036.

Similar to the read / write process applied to MsgO, the BlockingPtr pointer has been set to the last entry of the current Message and the Blocked condition has been set to "true" to prevent movement of the BlockingPtr once again.

At time t5 the read process is suspended. This behaviour has been introduced artificially to force a memory buffer full condition and demonstrate the steps taken when the memory buffer is full. Typically, the read process would continue at time t5 given the status of the memory buffer .

Figure 5c shows a schematic representation of the memory buffer at time t6. Figure 5c illustrates the status of the memory buffer after receiving the beginning of a new long message Msg2.

The start of a new, very long Message is received (e.g. Msg2 [0] ..Msg2 [64496] ) . The TWritePtr pointer has advanced accordingly the start of the message has been written to the memory buffer (locations 1038 to 65535) according to step 208.

The BlockingPtr pointer has not advanced due to the Blocked condition which is set to "true" . The read process has not yet resumed at time t6.

Figure 6a shows a schematic representation of the memory buffer at time t7. Figure 6a shows the status of the memory buffer when the memory buffer is full.

The read process has not continued reading the memory buffer 9 because the read process is still suspended. The TWritePtr pointer advances and ends up at the same location as the AppReadPtr pointer (e.g. location 1030) .

The TWritePtr pointer has wrapped around the memory buffer and has written Msg2 [64497] to Msg2 [64502] to locations 1024 to 1029. This overwrites the previously read MsgO . Since the memory buffer locations beyond the TWritePtr pointer have not been read, the TWritePtr pointer cannot overwrite these locations. In other words, there is a memory buffer full condition at time t7 and the Write Process has to suspend. This is shown in decision block 222, which tests if the flag BufFull is "true" , If so then decision block 224 is executed which tests whether the Blocked flag is set to "true" . If the Blocked flag is set to "true" then the decision block 222 is executed. If both BufFull and Blocked are set to true, then the decision blocks form an endless loop until the memory buffer is not full. That is, the write process is suspended.

Figure 6b shows a schematic representation of the memory buffer at time t8. Figure 6b shows the status of the memory buffer after the read process has resumed.

The read process has resumed; the AppReadPtr pointer has advanced by one location (to location 1031) and points to the MessageStartLocation field of the next message. This causes updating of AppCurMsgPtr pointer and checking of MsgStatus. MsgΞtatus has been already set to Finalized and the AppNextMsgAdr is updated to point to the start of the next MessageStartLocation entry (e.g. location 1036) .

Figure 6c shows a schematic representation of the memory buffer at time t9. Figure 6c shows the status of the memory after the Msgl was read.

The read process has continued processing Msgl . The AppReadPtr pointer advances to the same position as the BlockingPtr pointer. Similarly to the process outlined above, this causes normal data reading to stop and checking of the MessageStartLocation entry (steps 312 and 320) , which the AppCurMsgStartPtr is referencing to, to stop.

In addition, the Blocked condition has been set to false because the AppReadPtr pointer points to the same location as the BlockingPtr pointer (step 312) and the EndCurMsg indication has been set to true (step 316) because the last portion of the current Message has been read (step 314) .

It is possible at this time that the write process may not have received new segments of the message. Decision block 226 tests whether the condition of MsgSeglnd is set to "true" (that is if a new segment has arrived) . In decision 226 if MsgSeglnd test to not "true" then wait at the same block until it gets a new message segment. There may be a situation where the data processing unit 3 has not received new message segments and therefore the write process does not continue.

Figure 7a shows a schematic representation of the memory buffer at time tlO. Figure 7a shows the status of the memory where the write process has proceeded.

The AppReadPtr pointer has advanced one location and the AppCurMsgStartPtr pointer has been updated. However, no new data has been read.

Reception of Msg2 has continued and the TWritePtr pointer has moved accordingly. The BlockingPtr pointer has followed the TWritePtr since the Blocked condition is set to false. Msgl has been overwritten (locations 1031 to 1035) with further portions of Msg2. Figure 7b shows a schematic representation of the memory buffer at time til. Figure 7b shows the status of the memory buffer where the read and write process has further proceeded.

The read process has started processing Msg2 and has read the first portion of Msg2 {e.g. Msg2 [0] to Msg [64505] at locations 1038 to 1032) .

The AppReadPtr pointer has encountered a wrap-around. That is the AppReadPtr pointer has read a portion (Msg2 [64496] at location 65535) of the message (Msg2) in the last entry in the memory buffer and proceeded to read the next portion (Msg2 [64497] at location 1024} of the message in the first entry of the memory buffer.

The AppCurMsgStartPtr pointer and the AppNextMsgAdr pointer have kept the same location (e.g. location 1036).

The Write Process has received the end of the current message. The beginning of the same Message has been overwritten because this part has already been read by the read process.

While advancing the TWritePtr pointer and the BlockingPtr pointer of the Write Process have skipped MessageStartLocation fields to prevent overwriting these locations. This is achieved by means of the CurMsgStartPtr pointer. Decision block 230 tests whether the TWritePtr pointer is at the same location as the

CurMsgStartPtr pointer. If the TWritePtr pointer is at the same location as the CurMsgStartPtr pointer, then the TWritePtr pointer moves over the MessageStartLocation fields as shown in step 232. After reception of the end of the current Message (Msg2) the MessageStartLocation field is updated (locations 1036, 1037 are updated with "Finalized", "65534" respectively) and the CurMsgStartPtr pointer pointing to the start of the next expected Message is updated. The CurMsgStartPtr pointer points to location 65534.

The BlockingPtr pointer has been set to the last entry of the current Message and the Blocked condition has been set to true to prevent movement of the BlockingPtr pointer once again.

The memory buffer initialises and prepares to receive another possible message and write it into the memory buffer. Therefore the locations 65534 and 65535 are initialized with the current Message status (NotFinalized) and the start location of the next message respectively. Similar to the process previously described the start location of the next message is not known yet and therefore set to the start of the current message .

Figure 7c shows a schematic representation of the memory buffer at time tl2. Figure 7c shows the status of the memory buffer when all messages have been completely read.

The Read Process has continued processing Msg2 and the AppReadPtr pointer has advanced to the same position as the BlockingPtr pointer, which causes normal data reading to stop and checking of the MessageStartLocation entry, which the AppCurMsgStartPtr pointer is referencing to, and stops . In addition, the Blocked condition has been set to "false" because the AppReadPtr pointer points to the same location as the BlockingPtr pointer does and the EndCurMsg indication has been set to "true" because the last portion of the current Message has been read.

Again, the write process has not advanced because a new message may not have been received. At this point all received messages have been processed by the write process and the read process.

Embodiments of the present invention process messages which may be transmitted and received in one or more segments.

Typically, the end of the message is indicated in the last segment of the message. Therefore, the present invention may be applied to a flow control mechanism such as a credit based flow control mechanism. Such a flow control mechanism may not allow a transmitter to send more data than the receiver can consume .

Prior to the start of message transfer, for example during connection setup or start up of the communication system, the receiver communicates its memory buffer size in credits . A credit is a portion of data of a particular size. The receiver also communicates its message overhead. The message overhead specifies a fixed number of bytes that the receiver needs per message for managing them. This means that the transmitter allocates a proportion of each message to the message overhead. The message overhead may also overcome different word sizes of applications running at both receiver and transmitter entities. A word size is a fixed sized group of bits that are handled together by a processor (for example, 16, 32 or 64 bit) . In addition to the message overhead comprising location information {e.g. MessageStartlocation - the location of the start of the next message and the status information) the message overhead may further comprise a part for calculating the bytes needed for word alignment.

The above described operations may require data processing in the various entities . The data processing may be provided by means of one or more data processors . Similarly various entities described in the above embodiments may be implemented within a single or a plurality of data processing entities and/or data processors . Appropriately adapted computer program code product may be used for implementing the embodiments, when loaded to a computer . The program code product for providing the operation may be stored on and provided by means of a carrier medium such as a carrier disc, card or tape.

The present invention is described herein with reference to examples of preferred embodiments for the purpose of illustration, and is not limited to any such embodiments. The scope of the present invention is defined by the appended claims .

Claims

1. A method of writing data to a memory comprising: receiving a first message having a first data part ; writing the first message to the memory,- and writing location information for a subsequent message to a location in said memory.

2. A method according to claim 1 wherein the method further comprises the step of deriving the location information after the first data part is received.

3. A method according to claims 1 or 2 wherein the location information is written in a location in the memory adjacent to the first message.

4. A method according to any of the preceding claims wherein the method further comprises updating the location information.

5. A method according to claim 1 wherein the method further comprises validating the location information.

6. A method according to claim 5 wherein the method further comprises deriving validation information associated with the location information.

7. A method according to claims 5 or 6 wherein the validation information is written in a location in the memory adjacent to the first message or the location information.

8. A method according to claims 6or 7 wherein the step of validating is carried out after receiving the end of the first message.

9. A method according to claim 8 wherein the end of message is indicated by an end of message flag.

10. A method according to claims 8 or 9 wherein the location information is an available location in the memory buffer after the end of first message.

11. A method according to any of the preceding claims wherein the method further comprises the step of writing the subsequent message starting at the location information.

12. A method according to claims 5 to 11, wherein the step of writing the subsequent message is carried out if the location information is valid.

13. A method according to any of the preceding claims wherein the memory is a memory buffer.

14. A method according to any of the preceding claims wherein the location information and the validation information are protected when receiving the message.

15. A method according to claim 14 wherein protection information indicates whether the location information and the validation information are protected

16. A method according to claims 14 or 15 wherein the location information and the validation information are not protected if the location information is valid.

17. A method according to claims 14 to 16 wherein the step of updating also updates whether the location information and the validation information are protected or not .

18. A method according to any of the preceding claims wherein the memory buffer is cyclical.

19. A method according to any of the preceding claims wherein the message is one message segment or a plurality of message segments .

20. A method according to any of the preceding claims wherein the step of writing is suspended if the memory buffer is full.

21. A method according to any of the preceding claims wherein a write pointer progress is used for the memory buffer to indicate the next memory block to be written.

22. A method of managing data in a memory comprising: receiving a first message having a first data part ; writing the first message to the memory,- and writing location information for a subsequent message to a location in said memory; and reading the data from the memory.

23. A method of managing data according to claim 22 wherein a read pointer progresses through the memory buffer and indicates the next memory block to be read.

24. A method of managing data according to claims 22 or 23 wherein the step of reading is suspended if a blocking condition indicates that unread blocks of the memory- buffer are unavailable to be read.

25. A method of managing data according to claim 24 wherein the blocking condition indicates that unread blocks are available if the location information is read.

26. A method of managing data according to claims 22 to 25 wherein the steps of writing and reading are concurrent .

27. A memory managing unit comprising: a data processing unit; and a memory; wherein the data processing unit is arranged to: receiving a first message having a first data part ; writing the first message to the memory; and writing location information for a subsequent message to a location in said memory.

28. A memory managing unit according to claim 27 wherein the data processing unit is arranged to read the data from the memory.

29. An apparatus in a communication network having: an interface for receiving messages from the communication network; a data processing unit configured to receive messages from the interface; and a memory; wherein the data processing unit is arranged to: receive a first message having a first data part ; write the first message to the memory; and write location information for a subsequent message to a location in said memory.

30. An apparatus according to claim 29 wherein the data processing unit is arranged to read the data from the memory .

31 A computer program comprising program code means adapted to perform the following steps: receiving a first message having a first data part; writing the first message to the memory; and writing location information for a subsequent message to a location in said memory.

32. An apparatus in a communication network having: an interface means for receiving messages from the communication network; a data processing means configured to receive messages from the interface; and a memory means ; wherein the data processing means is arranged to: receive a first message having a first data part ; write the first message to the memory; and write location information for a subsequent message to a location in said memory.