Method and device for communication with short batches of data completed in mobile phone

FIELD: physics, communication.

SUBSTANCE: invention is related to transmission of information in global distribution network, such as Internet. Method for sending of information to target mobile station in anticipation mode includes definition of whether information should be sent in the form of short data batches (SDB) messages, and information sending in the form of SDB not waiting for reset of traffic channel.

EFFECT: development of mechanism for determination of messages to be transmitted in the form of SDB, so that no time-sensitive messages are delayed.

24 cl, 12 dwg

The technical field to which the invention relates

The present invention relates to the transferred information in a global distributed network such as the Internet. More precisely, the present invention relates to methods and devices for determining whether to send the information to the target communication device in the format of a short data packet without waiting that the channel was activated when the target communication device is in standby mode.

The level of technology

When the datagram the Internet Protocol (IP)that carry the information for the target communication device is sent from nodes of the packet data service (PDSN) controller base station/control functions package (BSC/PCF), while the packet data session is waiting, BSC/PCF must determine whether the information to be sent in short packets of data (SDB). One of the algorithms must use the size of the received information packet as filtering criteria. That is, when the accepted information package is found smaller than the predetermined size, the information packet may be sent to the target mobile station in the form of SDB on direct common channel, for example, without waiting for activation of the channel traffic. Otherwise, the channel traffic must be installed before sending inform the information package. This algorithm may not work well in a group call, for example, where clients and servers send messages, varying in size, when the data session is in the waiting state. However, not all of these messages are time-critical and therefore have no need to be sent in the form of SDB. Some large messages may need to be sent in the form of SDB, whereas some small messages may be necessary to deliver after the channel traffic reinstalled. The large size of the package as filtering criteria may initiate sending many small messages in the form of SDB and, therefore, causes a significant load on the shared channel. On the other hand, if you used a small packet size, the large messages that are time-critical, may not be immediately sent in the form of SDB.

Therefore, there is a need for mechanisms to determine which messages should be transmitted in the form of SDB, so that any time-sensitive messages are not delayed.

The invention

Disclosed embodiments of provide latest and improved methods and apparatus for determining the differences whether to send a short data packet information, etc is naznacheniya for the target mobile station. The method consists in the fact that you accept the information package intended target mobile station, analyze adopted an information packet and noted whether the information for transmission in the form of short messages data packet.

Disclosed embodiments of additionally provide you with the latest methods and apparatus for marking information for delivery of the short data packet (SDB) in a wireless data network. How is that encapsulate the information in the datagram, with the datagram includes a header portion, and mark the header of the datagram, so that the wireless infrastructure delivers the information encapsulated in a datagram to the destination in the form of SDB messages.

In another aspect the device to transmit information intended for the target mobile station, includes a storage device, a receiver, a transmitter, and a processor (processing unit) with the ability to communicate directly connected to the storage device, the transmitter and receiver. The processor can execute the commands to perform the above methods.

Brief description of drawings

Distinguishing features and advantages of the present invention will become more apparent from the detailed description disclosed in the of options for the implementation below, apprehended in connection with the drawings, in which:

Figure 1 illustrates the sequence diagram of operations call for delivery is completed on the mobile device short data packets;

Figure 2 illustrates the IP datagram, made in the form of a frame and encapsulated;

Figure 3 illustrates an implementation option for the base station and the mobile station;

Figure 4 illustrates the header of the IP datagram, as shown in figure 2;

Figure 5 illustrates the field type of service for the header part shown in Figure 4, according to one of embodiments;

6 illustrates a field type of service for the header part shown in Figure 4, according to another variant implementation;

Fig.7 illustrates the field type of service for the header part shown in Figure 4, according to another another variant implementation;

Fig illustrates an alternative header of the IP datagram, as shown in figure 2;

Fig.9 illustrates the frame structure for a PPP frame, shown in figure 2;

Figure 10 illustrates the analysis algorithm for the PPP frame, shown in figure 2;

11 illustrates the analysis algorithm for the header portion of the IP datagram is shown in Figure 4 and Fig; and

Fig illustrates a simplified analysis algorithm.

Detailed description

Figure 1 illustrates the sequence diagram of operations call for delivery is completed on the mobile device short data packets while waiting for the packet data session. During the waiting state supported point-to-point session (from point to point) Protocol (PPP), but the trafc channel is deactivated. Information on PDSN 102, for example, in the form of IP datagrams(s), is sent to the BSC/PCF 104 at step (b). BSC/PCF 104 makes a determination regarding how to send the information on the phase (c). At the stage (c) BSC/PCF 104 analyzes the received information. If the field type of service (TOS) in the header part of an approved IP datagrams marked for SDB-delivery, BSC/PCF 104 uses the steps from (d) to (g)to deliver information in the form of SDB. If the BSC/PCF 104 determines that the received information should be sent in the form of SDB, BSC/PCF 104 first performs the main search is isov, at stage (d)to localize the target mobile station. Subsequently, the information is sent in the form of SDB on a shared channel, for example, to the mobile station (MS) 106, at step (f). The target mobile station can be identified in the response message on the main search call to the mobile station, adopted at step (e). Otherwise, if the BSC/PCF 104 determines that the received information should not be sent in the form of SDB, BSC/PCF 104 relies on the mobile station controller (MSC) 108, to localize the target mobile station, for example, through the procedure of the main search call, re-sets the channel traffic and then sends the information. This procedure is not shown in the diagram.

In one embodiment, the network entity, such as a server 110 group call, can provide information for the target MS 106, in the form of an IP datagram. PDSN 102 encapsulates adopted IP datagram before it is sent to the BSC/PCF 104. Figure 2 illustrates the sequence of operations construction of IP datagrams according to one of embodiments. IP datagram 202 may include a header part and an information part. If the PDSN 102 PPP is a peer device in relation to the MS, the PDSN 102 may encapsulate adopted IP datagram 202 inside the PPP header 204 and PPP-tail 206 forming the PPP to the others 208.

According to one of embodiments, as described in TIA/EIA/IS-2001, "Interoperability Specification (IOS) for cdma2000 Access Network Interfaces" ("Specifications compatibility (IOS) for network access interfaces cdma2000"), dated August 2001, (IOSv4.1), before sending the information to the BSC/PCF 104, PDSN 102 adds the header 210 of the multicast routing encapsulation (GRE) and IP header 212 to the PPP frame 208, forming a GRE packet 214. GRE packet 214 is treated as the payload of the IP and sent to the BSC/PCF 104, for example, channel A10.

After taking the GRE packets 214 BSC/PCF 104 removes the GRE header 210 and the IP header 212 of the received GRE packet 214 and can add the appropriate headers before sending information over terrestrial interface of the target MS 106. As discussed above, when the packet data session is pending, BSC/PCF 104 must be checked adopted the PPP frame 208 to determine where the header portion of the IP datagram 202, before starting the analysis of the IP datagram 202, as will be discussed in detail later in this patent document.

It is possible that a single GRE packet 214 contains incomplete PPP-frame or multiple PPP frames as specified in TIA/EIA/IS-835, "Wireless IP Network Standard ("the Standard for wireless IP networks"), dated 6 December 2001. In such cases, the standard prescribes that the sequence number field included in the GRE header 210 may be used to ensure that the placenta is therefore the delivery of packets. If the sequence number of the GRE header 210 is allowed, BSC/PCF 104 re-arranges the received GRE packets before analysis of the PPP frame.

Figure 3 is a simplified block diagram of a variant of implementation of the BSC/PCF 304 and the mobile station 306, which allow implementing various disclosed embodiments. For specific data, voice data, packet data and/or messages may be exchanged between the BSC/PCF 304 and the mobile station 306 through the ether interface 308. Can be transferred to different types of messages, such as messages used to establish the communication session between the BSC/PCF 304 and the mobile station 306, message reception and retrieval of call and messages used to control the transfer of data (for example, capacity management, information about the speed of data transfer, confirmation and so on). Some of these message types are described in more detail below.

For the return line at the BSC/PCF 306 voice and/or packet data (e.g., from the source data 310) and messages (for example, from the controller 330) are provided to the processor 312 data transmission (TX), which formats and encodes the data and messages using one or more coding schemes to generate coded data. Each encoding scheme may include any combination of control with excessive qi is symbolic code (CRC), convolution, fast and other coding, or no coding at all. Voice data, packet data and messages can be encoded using different schemes, and different types of messages can be encoded in different ways.

The coded data is then provided to a modulator (MOD) 314 and further processed (e.g., masked, compressed on the spectrum of short PN sequences and scrambled large PN sequence assigned to the user terminal). The modulated data is then provided to the device transmitter (TMTR) 316 and brought into the desired state (e.g., converted to one or more analog signals, amplified, filtered, and quadrature modulated)to generate the feedback signal line. The signal return line is routed through the antenna switch 318 (D) and transmitted via the antenna 320 BCF/PCF 304.

On BCF/PCF 304 signal return line connection is made antenna 350 is sent through the antenna switch 352 and is provided to the receiver unit (RCVR) 354. BSC/PCF 304 may receive the registration information and the status information, for example information about the localization of the mobile station, from the mobile station 306. The receiver unit 354 leads to the desired state (e.g., filters, amplifies, converts with decreasing frequency and otsifrovana the t) the received signal and provides samples. A demodulator (DEMOD) 356 receives and processes (e.g., eliminates compression, remove the masking and demodulates the pilot signal sample to provide recovered symbols. The demodulator 356 may implement multi-tap (rake) receiver, which handles numerous variations of the received signal and generates the combined symbols. The device 358 data reception (RX) then decodes the symbols to recover the data and messages transmitted on the reverse link. The recovered voice/packet data provided to the data receiver 360, and recovered messages may be provided to controller 370. The controller 370 may include commands to search and call a group of mobile stations, which may be based on the mobility of the mobile stations. The processing by demodulator 356 and devices 358 handle RX data are complementary to the same executed at the base station 306. The demodulator 356 and the device 358 handle RX data can additionally be controlled to handle multiple transmission signals received through multiple channels, such as reverse main channel (R-FCH) and a reverse channel (R-SCH). Also, the transmission signals can be simultaneously from multiple mobile stations, each of which m which may be transmitting on the reverse main channel, reverse-band, or both.

In a straight line at the BSC/PCF 304 voice and/or packet data (e.g., from a source 362 data) and messages (for example, from the controller 370) are processed (e.g., formatted and encoded) by the device 364 data reception (TX), further processed (e.g., masked and compressed spectrum) modulator (MOD) 366 and provides the desired condition (e.g., converted to analog signals, amplified, filtered, and quadrature modulated) by block 368 (TMTR) receiver to generate a signal straight line. The signal straight line goes through the antenna switch 352 and transmitted through the antenna 350 in the BSC/PCF 306. Signals direct line of communication include signals search call.

At the BSC/PCF 306 signal direct communication line is received by the antenna 220 is routed through the antenna switch 318 is provided to block 322 receiver. Block 322 receiver leads to the desired state (for example, converts with decreasing frequency, filters, amplifies, quadrature modulates, and digitizes) the received signal and provides samples. Samples are processed (for example, eliminating compression, removed the masking and demodulated pilot signal) by the demodulator 324 to provide the symbols, but the symbols are additionally processed (for example the EP, are decoded and checked) device 326 data processing device to restore the data and messages transmitted in a straight line. The recovered data are provided to the receiver 328 data, and the recovered messages can be provided to the controller 330. The controller 330 may include commands for the BSC/PCF 306, which may be based on the mobility of the mobile station.

Bits type of service (TOS) IP

Figure 4 illustrates the header of the IP datagram 202, shown in figure 2, according to one of embodiments, for example, IP version 4 (IPv4). Field 402 type of service (TOS) IP is the second byte within the header portion of the IP datagram 202. There are three widespread compliance TOS-bits definition service for IPv4. The first match is defined in RFC (Requests for comments the problem of designing the Internet) 791, "Internet protocol" ("Internet Protocol"), from September 1981 In this RFC the TOS field has five subfields, as shown in Figure 5. Three-bit precedence set precedence IP datagram values with values that are located in the range from zero (normal seniority) to seven (control network), allowing senders to specify the importance of each IP datagram. The following three bits are "D", "T" and "R". These bits can be used in isolani, to specify the type of transport IP datagrams. The last two bits are reserved bits. In one of the embodiments, the server 110 group call uses one or both of the reserved bits in the TOS field of the IP datagram to indicate that the wireless infrastructure, as shown in Figure 3, for example, send the IP datagram to the target mobile station in the form of SDM messages.

6 illustrates another under the TOS bits to define maintenance as defined in RFC 1439, "Type of Service in the Internet Protocol Suite" ("Type of service in the set of Internet protocols"), from June 1999, Despite the fact that this RFC updates the definition in RFC 791, many printed materials and the implementation still refer to the original definition in RFC 791. In RFC 1439 subfield of precedence is the same as that defined in RFC 791. The following four bits are considered as a bit type of service (TOS), and the last bits as bits that must be zero (MBZ) bit. RFC 1439 overrides bits "D", "T", "R" as a 4-bit TOS field. RFC 1439 prescribes that the Creator of the datagram sets the last bit to zero, except for participation in the experiment of the Internet Protocol, which shall use the last bit. So this leaves only the last bit as the unused bits. In one of the embodiments, the server 110 group call uses reserved bits in the TOS field to indicate that the wireless infrastructure, as shown in Figure 3, for example, send the IP datagram to the target mobile station in the form of SDM messages.

7 illustrates the third definition of service defined by the differential structure of the maintenance problem of the design group of the Internet engineering task force (IETF)as described in RFC 2474, "Definition of Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers" ("definition of the differentiated services field (DS field) in the IPv4 and IPv6 headers"), dated December 1998, This definition uses the 6-bit code is given differentiated service (DSCP)to specify the interpretation of the behavior at each stage of transmission (PHB) for IP datagrams. The last two bits are reserved bits. In one of the embodiments, the server 110 group call uses one or both of the reserved bits in the TOS field to indicate that the wireless infrastructure, which is shown in Figure 3, for example, send the IP datagram to the target mobile station in the form of SDM messages.

Fig illustrates the header of the IP datagram 202 (2) for IP version 6 (IPv6) RFC 2460, "Internet Protocol, Version 6 (IPv6) Specification" ("Internet Protocol Specification version 6 (IPv6)"), from December, the 1998 Class 802 traffic is a one-byte field that directly continues the 4-bit field 804 version, as shown in Fig. RFC 2460 remains open in terms of what 8-bit class 802 traffic uses. However, there are active efforts by the IETF to adapt the definition of service for IPv6 is similar to the definition of the IPv4 service.

Returning to 6, given that the first 7 bits IPv4 header part can be used to meet the definition of service, the last bit may be used to indicate that the received information at the BSC/PCF 104 must be sent to the destination MS 106 in the form of an SDB message. RFC 1812, "Requirements for IP Version 4 Routers" ("Requirements for routers IP version 4"), dated June 1995, imposes requirements for IPv4 routers do not drop packets, if non-zero values used in the reserved bit(s). Existing RFC does not prescribe how other new protocols can use the reserved bits, so for BSC/PCF 104 is possible to accept IP datagrams during the listening session package data that includes a reserved bit(s)marked differently than zero. In addition, there are no requirements RFC that specifies how routers IPv6 must interpret the last bit of the 8-bit field traffic class in IPv6 header.

Later in this document is E. the term "the TOS field of IP used to specify and on the field 402 IPv4 TOS, and field 802 of the traffic class, IPv6, depending on the addressing scheme under consideration. According to one of embodiments a server group call shall use the unused bit(s) of the TOS field as a mechanism to specify SDB delivery. For example, for a message that should be sent in the form of SDB, servers group call can set the last bit of the IP TOS field in the value 0x01.

The point-to-point Protocol connections

As noted above, the GRE packet 214 (figure 2) can contain numerous PPP frames or incomplete PPP frame. BSC/PCF 104 retrieves the GRE header 210 and the IP header 212 of the received GRE packet 214, then repackage the information in the form of a frame Protocol radio link (RLP) and transmits the RLP frames on terrestrial interface of the target mobile station 106. To BSC/PCF 104 to analyze the TOS field of IP, BSC/PCF 104 detects the beginning and end of a PPP frame 208. In this section we study the structure of the PPP frame and identify the fields that can be put into circulation during the phase of communication control, as specified in TIA/EIA/IS-835, "PPP in HDLC-like Framing" ("the Standard for wireless IP networks"), dated 6 December 2001 More details about PPP can be found in RFC 1661, "The Point-to-Point Protocol (PPP)" ("point-to-point Protocol connection (PPP), July 1994

Fig.9 illustrates how high the level structure of the frame control data link (HDLC) PPP frame 208, according to RFC 1662, "PPP in HDLC-like Framing" ("PPP in HDLC-like structure"), from June 1994 Field 902 through 908 belong to the PPP header 204 PPP frame 208, and the field 912 specifies a reference to an IP datagram 202 PPP frame 208, and the field 912 indicates a reference to PPP-tail 206 PPP frame 208. The first field 902 is limiter "7E", to indicate the beginning and/or end of a PPP frame 208. The limiter continues HDLC-frames 904, 906, 908.

According to RFC 1662, the address field 904 may be set to the octet 0xFF, and control field 906 may be set to the octet 0x03. HDLC information field contains the field 908 Protocol and IP datagram (PPP payload) 910. For IP service field 908 Protocol includes two octets with the value be 0x0021, continued IP datagram 910. The last field of the HDLC packet is the check sequence frame (FCS) 912, which may include two or four octets. Each PPP frame begins with a sequence of frame divider, and one sequence of frame divider can be used between two frames. Two consecutive sequence delimiter frame are empty frame. End sequence separator frame figure 9 is not shown.

According to one of embodiments a control Protocol connection (link) (LCP) puts into circulation modifications to the standard HDLC-podobn the th frame, which was described above. Peer-to-peer PPP unit may agree to reduce field 904 address field 906 control. If the reduction is permitted, two octets are excluded. In addition, PPP peer device may agree to reduce field 908 Protocol to a single byte, for example 0x21. Another Treaty parameter is the number of bits for control of cyclic redundant code (CRC) field 912 FCS. Peer-to-peer PPP device can agree on a 16-bit CRC or 32-bit CRC.

PPP can perform the substitution of bits before the data is transmitted in order to achieve transparency for the control characters. Managing octet passes can be selected to be 0x7D. At least, RFC 1662 requires the implementation to skip the sequence separator, for example, 0x7E, and control octets passes, 0x7D. After calculation of the FCS transmitter verifies the full frame between the two sequences limiter and performs the skip sequence separator. Values between 0x00 and 0x1F (inclusive) plus the value 0x7D and 0x7E can be ignored by the transmitter when sending a PPP frame.

The symbol table asynchronous management (ACCM) is an optional element LPC containing chetyrehstennoy bit table, which enables (bit set) or disables (bit is cleared) missing symbol to control what their characters ASCII-32 (32-bit American standard code for information interchange) in the range from 0x00 to 0x1F. For example, the first octet of the value ACCM contains bits to control characters from 0x19 up to 0x1F, with the MSB (the highest bit)indicating 0x1F, and the LSB (the low order bit)indicating 0x18. The second octet contains bits for characters from 0x10 to 0x17 and so on. The value 0xFFFFFFFF indicates that all control characters are ignored, according to the "PPP Design, Implementation, and Debugging", Carlson, James, Addison-Wesley, 2002 ("the Design, implementation, and commissioning of PPP", Carlson James, Edison-Wesley, 2002). The value ACCM 0x00000000 specifies that none ASCII character with values between 0x00 and 0x1F was not skipped. Each sequence limiter, managing octet crawl, and any octet, which is marked in the send ACCM, is replaced managing octet crawl, for example, 0x7D, continued the original octet subjected to EXCLUSIVE OR operation (XOR operation) with octet 0x20.

For operations and simple IP and mobile IP, TIA/EIA/IS-835, "Wireless IP Network Standard ("the Standard for wireless IP networks"), dated 6 December 2001, requires bypass control for mobile devices and for PSDN. For PSDN standard requires from the PDSN to establish compliance with control characters with a minimum number of skipped characters by providing a value ACCM 0x00000000. On the other hand, the standard recommends that if MS puts into circulation under the control characters, it should strive for the minimum number of the TSS crawls through the issuance ACCM 0x00000000. Therefore, it is possible to BSC/PCF 104 took PPP frames from the PDSN 102, where not only the sequence of the limiter, but also characters from 0x00 and 0x1F skipped.

When the BSC/PCF 104 is not PPP peer device PDSN, BSC/PCF 104 may not be aware of in which LCP parameters, such as field 906 control field 904 addresses and field 908 Protocol entered into circulation between the MS 106 and the PDSN 102. Therefore, except for the definition of a PPP structure, BSC/PCF 104 determines which field is reduced, and whether any characters crawled to identify the beginning of the header portion of the IP datagram 202, to parse the IP TOS bits. The following section describes the algorithm that the BSC/PCF 104 uses to analyze the PPP frame.

The analysis algorithm PPP frame

As noted above, the GRE packet 214 received at the BSC/PCF 104 may contain numerous PPP frames or partial frames that require BSC/PCF 104 to analyze the flow of packet data during the waiting state, to determine the sequence of the limiter PPP frame. The algorithm that the BSC/PCF 104 uses to analyze the flow of information to determine the beginning of the header portion of the IP datagram 202, shown in Figure 10.

If the algorithm detects a certain sequence of characters, then the algorithm skips to the beginning of a PPP frame, pascalc what he cannot know, where the PPP frame 204 begins. This event can occur as a result of unsuitable PPP implementation, or when there are one or more errors in the data stream. The algorithm compares the sequence limiter "0x7E" until then, until you find a non-empty PPP frame. More precisely, after finding the first delimiter 0x7E at step 1002 the next byte is checked for the delimiter 0x7E at step 1004. If the next byte contains another delimiter 0x7E, which means that the PPP frame after the analysis is empty, sequence of operations continues checking the next byte at step 1006. However, if the byte following the byte containing the first stop 0x7E, does not contain the delimiter 0x7E, meaning that the detected non-empty PPP frame, the sequence of operations checks to field 904 addresses at step 1008.

In one embodiment, the implementation of field 904 address field 906 control can be reduced and continue missing. In addition field 908 Protocol can also be reduced, so that it may be presented only his second byte with the value 0xFF. In such cases, according to RFC 1662, the second byte dohaqatar field 908 Protocol should not be set to 0xFF to avoid that he was wrongly perceived as a field 904 addresses with the value 0xFF

Continuing the test at step 1008 and looking 0xFF corresponding field 904 addresses, BSC/PCF 104 checks in step 1010, contains in itself the next byte 0x03, 906 corresponds to the field of management. If at step 1010 it is determined that the next byte contains 0x03, BSC/PCF 104 checks whether it was the result of agreements with the issuance ACCM for control field is 0x03. After issuance ACCM BSC/PCF 104 first sends the byte crawl control, for example, 0x7D, and then the byte that contains the result of the exclusive or (XOR) byte source of information that must be sent, for example with 0x03 0x20.

At step 1012, BSC/PCF 104 checks for the existence of the byte 0x7D first, and if set, checks for the existence 0x23, which is the result 0x03 subjected to the XOR operation with 0x20 at step 1014. If 0x7D and 0x23 not found, meaning that no field 906 control is not detected, then the sequence of operations checks at the beginning of a new PPP frame at step 1016 and 1018, like stage 1002 and 1004, as described above. It should be noted that if the result at step 1008 is "no", then field 904 addresses reduced and, therefore, not presented.

If at step 1010 or step 1014, the result is "Yes", indicating that the detected value of 0x03, the corresponding field 906 control, directly sludge is through the introduction of the ACCM, the sequence of operations checks on the following bytes in the presence 0x00, corresponding to the first byte of the field 908 Protocol. BSC/PCF 104 may first check whether it was the result of the entry into circulation to send field 908 Protocol through the ACCM. At step 1020, if the byte 0x7D not found, meaning that the field 908 Protocol not going to send through the introduction of the ACCM, BSC/PCF 104 then checks, at step 1022, contains in itself the next byte 0x00 corresponding to the first byte of the field 908 of the Protocol.

After BSC/PCF 104finds 0x00, corresponding to the first byte of the field 908 Protocol, at step 1022, BSC/PCF 104 checks whether the result of the issuance was to send the second byte of the field 908 Protocol through the introduction of the ACCM. On the steps 1024, if the byte 0x7D not found, meaning that the field 908 Protocol not going to send through the issuance ACCM, BSC/PCF 104 then checks at step 1026, contains in itself the next byte 0x21 corresponding to the second byte of the field 908 Protocol. If 0x21 found at step 1026, the accompanying 0x00 found at step 1022, the sequence ends at step 1028 to analyze the header portion of the IP datagram 910, as will be described later in this patent document.

On the steps 1024, if found byte 0x7D, meaning that the field 908 Protocol are going to send through the commissioning of the treatment ACCM, the BSC/PCF then checks at step 1030, contains in itself the next byte of 0x01, which is the second byte of the field 908 Protocol, for example 0x21 subjected to the XOR operation with 0x20, according to the putting into circulation of the ACCM. If the byte 0x01 found at step 1030 accompanying 0x00, found at the step 1022, then the sequence ends at step 1028 to analyze the header portion of the IP datagram 910.

Returning again to step 1020 that finds the first byte of the field 908 Protocol, for example, 0x00, if BCF/PCF 104 finds 0x7D, then the following byte is checked for 0x20, which is the first byte of the field 908 Protocol, such as 0x00, subjected to the XOR operation with 0x20 at step 1032. If the result at step 1032 is "Yes", meaning that 0x00 is found in the first byte of the field 908 Protocol, the sequence of operations proceeds to step 1024, looking for the presence of the second byte of the field 908 Protocol, for example, 0x21, as discussed in detail above.

At step 1032, if the byte accompanying bytes containing 0x7D, does not contain the value corresponding to the first byte of the field 908 Protocol, for example, 0x00, BSC/PCF 102 determines at step 1034, whether bytes in itself 0x00, which is the second byte of the field 908 Protocol, for example 0x21 subjected to the XOR operation with 0x20. If the result is "Yes", then the sequence ends at step 1028. If the result field the ends, when not finding the second byte of the field 908 Protocol, for example, 0x21 sequence ends at step 1016, looking for the next PPP frame.

It should be noted that if the result at step 1022 is "no", meaning that the first byte of the field 908 Protocol is not found, the field is reduced. Thus, only the presence of the second byte, for example, 0x21 is checked at step 1036.

The analysis algorithm IP datagrams

As soon as the analysis algorithm PPP frame has reached the state 1028 "Analyze IP datagram", indicating that the algorithm successfully detected the beginning of the IP datagram 910, BSC/PCF 104 then uses an algorithm according to one of embodiments, which are shown at 11, to analyze the header portion 400 (Figure 4) or 800 (Fig) IP datagram 910 to detect whether SDB-label. In one embodiment, the implementation of the analysis algorithm assumes that the four bytes of the 32-bit header part 400 and 800 transmitted in the following order: bits 0-7 first, bits 8-15 bits 16-23 bits 24-31 at the end. This arrangement is called a byte order by seniority, which is the byte ordering used in all binary integers in TCP/IP headers as they cross the network. This arrangement is also called network byte order. If the BSC/PCF 104 stores a binary is in other formats, such as byte ordering in the minority, BSC/PCF 104converts the value of the header in network byte order before running the algorithm, or produces the corresponding mapping, so that the algorithm was executed properly.

Field 402 IPv4 TOS (Figure 4) and class 802 IPv6 traffic (Fig) begin with a 4-bit version field. 4-bit, the version field contains the version number of the IP. For versions IPv4 and IPv6 version number is 0x04 and 0x06, respectively. To determine the version number of the algorithm is shown figure 11, checks passed if the first byte of the header portion of the IP datagram 910 according to the putting into circulation of the ACCM or even directly. If it is found that the first byte of the header part contains 0x7D, at step 1102, meaning that the first byte of the header part put into circulation according to the ACCM, the algorithm then performs the XOR operation subsequent byte 0x20 at step 1104, in order to compensate for the XOR function with 0x20, consequently, restoring the original value.

At step 1106 the original contents of the first byte of the IP header is taken from step 1102, or the result, passed from step 1104, with the aim of extracting, undergo surgery AND from 0xF0 to read the first four bits of the header part. At step 1108, the result of step 1106 is checked at 0x60, to determine, indicate whether the first four bits of the header frequent is, what version is IPv6.

If the result of step 1108 indicates that the version is IPv6, then the sequence proceeds to steps 1110, 1112, 1114 and 1116 to determine if the fifth bit of class 802 traffic (Fig), indicating SDB-label. If the result of step 1116 indicates that bit SDB set, then the sequence ends at step 1118.

Continuing with step 1120, if the result indicates that the version number of the header part is IPv4, the sequence proceeds to the steps 1122, 1124, 1126 and 1128 to determine whether the eighth bit field 402 TOS (Figure 4), indicating SDB-label. If the result of step 1128 indicates that bit SDB set, then the sequence ends at step 1118.

As soon as SDB label is found, BSC/PCF 104 detects the following sequence limiter to find the end of a PPP frame in the test. More than two IP datagram where the first IP datagram contains SDB-label, can be encapsulated within a single PPP frame received at the BSC/PCF 104. In addition, the IP datagram with SDB label may exceed the expected amount. When any of the above two events occurs, it is expected that the received message is great. To prevent sending a SDB message on a shared channel during a session timeout packet is data, can be performed an additional check. At step 1130 detected the end of a PPP frame under consideration, and, if the number of bytes in a PPP frame is less than the allowed amount, as determined at step 1132, the PPP frame is sent in the form of SDB at step 1134. Otherwise, if the number of bytes in a PPP frame exceeds the permitted number, the channel traffic is reset to send the PPP frame at step 1136, not paying attention to SDB-tag.

The procedure that the BSC/PCF uses to convey SDB on terrestrial interface, shown in figure 1 according to one of embodiments. During the listening session packet data is likely that one PPP frame is MS 106 from PSDN 102. To avoid unnecessary processing, BSC/PCF 104can be a valid handle only a few PPP frames that arrive at the same time in the waiting time of the packet data.

A simplified algorithm analysis

In one of the embodiments, where put into circulation LCP options, the introduction of the ACCM and the IP addressing scheme known BSC/PCF 104, the above algorithms can be simplified. In such cases, the following configuration can be known, BSC/PCF 104:

Allowed the reduction of the address field 9904 and field 906 management

Allowed the reduction of the field 908 Protocol

ACCM has a value of 0x00000000

We use the scheme of the address is the IPv4

The PPP frame and algorithms analysis of the IP datagram is shown in Figure 10 and 11 respectively, are simplified in the aggregate, as shown in Fig, according to one of embodiments. After detecting a non-empty PPP frame at step 1202 sequence checks for the presence of the second byte of the field 908 Protocol, for example, 0x21, at step 1204, paying attention that the first byte of the Protocol field is removed at the time of issuance of reduction of the field. If found, the sequence skips the first byte of the header part, which is shown in figure 4, in order to achieve field 402 TOS at step 1206. At steps 1208 and 1210 sequence checks, such as whether the LSB of the field 402 TOS, which is shown in Fig.6, if so, the sequence of operations specifies SDB-tag at step 1212. The sequence then continues with steps 1220 1214 in order to check the size SDB messages, like steps 1130 on 1136 figure 11. If the dimensional criterion is satisfied, then the PPP frame is sent in the form of SDB. Otherwise, the channel traffic is reset at step 1220 to send a PPP frame.

Thus, the disclosed embodiments of provide efficient and reliable system and method for determining whether to be sent information intended target mobile station, which is in the standby mode in the form of SDB messages without waiting for the channel traffic will be reset.

Experts in the art should understand that information and signals may be represented using any of a variety of different technologies and protocols. For example, data, instructions, commands, information, signals, bits, symbols, and integrated circuits that could be referenced throughout the above description may be represented by the values of electrical voltage, current, electromagnetic waves, magnetic fields or particles, light fields or particles, or any combination thereof.

Individuals must additionally take into account that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the implementation disclosed in this patent document may be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above from the point of view of their functionality. Any such functionality is implemented as hardware or software, could be the cost from the particular application and design constraints imposed on the entire system. Qualified professionals can implement the described functionality in different ways for each particular application, but such implementation decisions should not be interpreted as servants by reason for exit from the scope of the present invention.

The various illustrative logical blocks, modules, and circuits described in connection with the implementation disclosed in this patent document may be implemented or executed by the processor of wide application, a digital signal processor (DSP), a specialized integrated circuit (ASIC), programmable gate array (FPGA) or other programmable logic device, discrete logic element or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described in this patent document. The wide application processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as combinations of a DSP and a microprocessor, a large number of microprocessors, one or more high performance embedded is sorow in conjunction with a DSP core, or any other such configuration.

The stages of a method or algorithm described in connection with the implementation disclosed in this patent document may be implemented directly in the hardware, the software, executable by a processor, or in a combination of these two. A software module may reside in RAM (random access memory, RAM), flash memory, memory, ROM (read only memory device, ROM), EEPROM memory (electrically programmable ROM, EPROM), EEPROM (electrically erasable and programmable read-only memory, EEPROM), registers, hard disk, removable disk, ROM, CD-ROM (CD-ROM) or any other form of storage medium known in the art. An exemplary storage medium connected to the processor so that the processor can read information from and write information on the information carrier. In the alternative case, the recording medium can be combined with the processor. The processor and the storage medium may reside in an ASIC. ASIC may reside in a user terminal. In an alternative embodiment, the processor and the storage medium may reside in a user terminal in the form of discrete components.

Description of the disclosed embodiments is provided to provide any specialist in this is blasti technology the ability to make or use the present invention. Various modifications to these embodiments may be readily apparent to experts in the field of technology, and the fundamental principles defined in this patent document can be applied to other variants of implementation, for example in the service, instant messaging or any other applications wireless data transmission from the comfort of the essence or scope of the invention. Thus, the present invention has no intention to be limited options for the implementation shown in this patent document, but should be aligned with the widest scope consistent with the principles and the latest features disclosed in this patent document. The term "exemplary" used in this patent document solely to indicate "used as an example, an incident or illustration".

1. The way to determine that is marked for transmission over a wireless communication network in the form of short data packet (SDB) information intended for the target mobile station, namely, that take an information packet destined for a target mobile station; parse a received information packet, and syntactic analysis includes detection of SDB label; determine the amount, that adopted an information packet is marked for delivery SDB based on the detected SDB-tag.

2. The method according to claim 1, wherein the information packet includes a header part and an information part.

3. The method according to claim 2, in which the aforementioned parsing includes parsing the header part.

4. Readable by the processor, the storage medium containing at least one command that, when executed by the processor, instructs the processor to perform a method of determining whether have noted for transmission over a wireless communication network in the form of short data packet (SDB) information intended for the target mobile station, and at least one command comprises at least one team information packet destined for a target mobile station; at least one command to parse a received information packet, and at least one command syntax analysis includes detection of SDB label; at least one team determine that the adopted information packet is marked for delivery SDB, on the basis of the detected SDB-tag.

5. Readable by the processor, the storage medium according to claim 4, in which the information packet includes a header part and an information part.

6. Readable by the litter storage medium according to claim 5, where the aforementioned at least one command parsing includes parsing the header part.

7. A device for determining the differences whether for transmission over a wireless communication network in the form of short data packet (SDB) information intended for the target mobile station containing means for receiving an information packet destined for a target mobile station; means for parsing the received information packet, and a means for parsing includes means for detecting SDB label; means for determining that the adopted information packet is marked for delivery SDB, on the basis of the detected SDB-tag.

8. The device according to claim 7, in which the information packet includes a header part and an information part.

9. The device according to claim 8 in which the said means for parsing includes means for parsing the header part.

10. A device for determining the differences whether to send more stable wireless connection in the form of short data packet (SDB) information intended for the target mobile station containing a receiver configured to receive information; a transmitter configured to transmit information to the target mobile is th station; and the processor is configured to receive an information packet destined for a target mobile station; parsing the received information packet, and syntactic analysis includes detection of SDB label; and determining that the adopted information packet is marked for delivery SDB, on the basis of the detected SDB-tag.

11. The device according to claim 10, in which the information packet includes a header part and an information part.

12. The device according to claim 11, in which the aforementioned parsing includes parsing the header part.

13. The manner of marking information for delivery of the short data packet (SDB) in a wireless communication network, namely, that encapsulate the information in the datagram, with the datagram includes a header portion; and note the header of the datagram, so that the wireless infrastructure delivers the information encapsulated in a datagram to the destination in the form of SDB messages.

14. The method according to item 13, in which said mark includes a mark type field (TOS) header part.

15. The method according to item 13, in which said mark includes a mark field traffic class header part.

16. Readable by the processor, the storage medium containing at least one command is, which when executed by a processor, instructs the processor to perform a method of marking information for delivery of the short data packet (SDB) in a wireless communication network, and at least one command includes at least one command encapsulation information in the datagram, with the datagram includes a header portion; and at least one command to mark the header part of the datagram, so that the wireless infrastructure delivers the information encapsulated in a datagram to the destination in the form of SDB messages.

17. Readable by the processor, the storage medium according to clause 16, in which the mentioned at least one team mark includes a mark type field (TOS) header part.

18. Readable by the processor, the storage medium according to clause 16, in which the mentioned at least one team mark includes a mark field traffic class header part.

19. Device for marking information for delivery of the short data packet (SDB) in a wireless communication network containing a means for encapsulating information in the datagram, with the datagram includes a header portion; and means for marking the header part of the datagram, so that the wireless infrastructure delivers the information encapsulated in a datagram to the destination in the form of a DB-messages.

20. The device according to claim 19, in which the said means for marking comprises means for marking the type of the field (TOS) header part.

21. The device according to claim 19, in which the said means for marking includes a tool to mark the field traffic class header part.

22. Device for marking information for delivery of the short data packet (SDB) in a wireless communication network containing a receiver configured to receive information; a transmitter configured to transmit information to the target mobile station; and a processor, configured to encapsulate the information in the datagram, with the datagram includes a header portion; and mark the header part of the datagram, so that the wireless infrastructure delivers the information encapsulated in a datagram to the destination in the form of SDB messages.

23. The device according to item 22, in which said mark includes a mark type field (TOS) header part.

24. The device according to item 22, in which said mark includes a mark field traffic class header part.