throbber
Case 1:22-cv-22706-RNS Document 1-30 Entered on FLSD Docket 08/25/2022 Page 1 of 12
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`EXHIBIT M
`
`

`

`USOO8792432B2
`
`(12) United States Patent
`Martin et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 8,792,432 B2
`Jul. 29, 2014
`
`(54) PRIORITIZING RACH MESSAGE CONTENTS
`
`(75) Inventors: Brian Martin, Farnham (GB); Keiichi
`Kubota, Weybridge (GB)
`
`(73) Assignee: Broadcom Corporation, Irvine, CA
`(US)
`
`(*) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 435 days.
`
`(21) Appl. No.: 13/026,512
`
`(22) Filed:
`
`Feb. 14, 2011
`
`(65)
`
`Prior Publication Data
`US 2012/O2O71O2A1
`Aug. 16, 2012
`
`(2009.01)
`
`(51) Int. Cl.
`H0474/00
`(52) U.S. Cl.
`USPC ........................................... 370/329; 370/331
`(58) Field of Classification Search
`USPC .......... 370/329, 331:455/436,437, 438,442,
`455/443, 444
`See application file for complete search history.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`6,487,420 B1 * 1 1/2002 Jonsson ........................ 455,522
`6,845,238 B1* 1/2005 Muller .........
`... 455,436
`6,847,420 B2 *
`1/2005 Lazarev et al. ..
`... 349,96
`2004/0228313 A1* 1 1/2004 Cheng et al. .................. 370,342
`2008/0045213 A1
`2/2008 Norris et al. ............... 455,435.1
`
`FOREIGN PATENT DOCUMENTS
`
`EP
`EP
`
`1720 373 A1 11/2006
`172O373 A1 * 11, 2006
`
`
`
`OTHER PUBLICATIONS
`3GPP TSG RAN WG2 Meeting #71, R2-104524, Madrid, Spain,
`Aug. 23-27, 2010, Nokia Corporation, "Addition of Optimised
`RACH Message Types’, (16 pages).
`3GPP TSG-RAN WG2 Meeting #71 bis, R2-105713, Xian, China,
`Oct. 11-15, 2010, Nokia Corporation, Nokia Siemens Networks,
`"Analysis on RACH Signalling”. (6 pages).
`3GPP TSG-RAN WG2 Meeting #72 bis, R2-1 10304, Dublin, Ire
`land, Jan. 17-21, 2011, Renesas Electronics Europe, “RACH Signal
`ling Optimisation Considerations', (4 pages).
`"Addition of optimised RACH message types”, Nokia Corporation,
`3GPP TSG-RAN WG2 Meeting #71, R2-104524, Aug. 2010, 15 pgs.
`"Analysis on RACH signalling, Nokia Corporation, 3GPP TSG
`RAN WG2 Meeting #71bis, R2-105713, Oct. 2010, 5 pgs.
`"3" Generation Partnership Project; Technical Specification Group
`Radio Access Network Radio Resource Control (RRC); Protocol
`specification (Release 10), 3GPP TS 25.331 V10.2.0, Dec. 2010, 42
`pg.S.
`
`* cited by examiner
`Primary Examiner — Andrew Lai
`Assistant Examiner — Sumitra Ganguly
`(74) Attorney, Agent, or Firm — Stanton IP Law
`(57)
`ABSTRACT
`A network/base station broadcasts an indication to direct a
`user equipment how to prioritize information for inclusion in
`an uplink message to be sent on a random access channel
`RACH. By example one value of the indication directs a user
`equipment UE to prioritize inter-frequency over intra-fre
`quency neighbor cell measurements for inclusion in the
`uplink message; and another value (or absence) of the indi
`cation directs a UE to prioritize intra-frequency over inter
`frequency neighbor cell measurements for inclusion in the
`uplink message. A UE receiving the broadcast indication
`constructs the uplink message which includes information
`that is prioritized in accordance with the indication so as not
`to exceed a maximum message size. There are also embodi
`ments with second and/or further/third indications in the
`broadcast system information for more efficiently utilizing
`the available space in the RACH message, which by example
`is an RRC Connection Request message in which UE capa
`bility information may be prioritized higher or lower than the
`measurement information.
`14 Claims, 4 Drawing Sheets
`
`Case 1:22-cv-22706-RNS Document 1-30 Entered on FLSD Docket 08/25/2022 Page 2 of 12
`
`210
`
`

`

`U.S. Patent
`
`Jul. 29, 2014
`
`Sheet 1 of 4
`
`US 8,792,432 B2
`
`
`
`Case 1:22-cv-22706-RNS Document 1-30 Entered on FLSD Docket 08/25/2022 Page 3 of 12
`
`

`

`U.S. Patent
`
`Jul. 29, 2014
`
`Sheet 2 of 4
`
`US 8,792,432 B2
`
`
`
`Network broadcasts E.
`prioritisation informat
`BCCH
`
`UEtriggers connection
`establishment, RRC
`Connection Request message
`is constructe
`
`8
`
`oes message size
`exceed the
`
`Transmit RRC
`
`Reguestion
`
`S
`
`Case 1:22-cv-22706-RNS Document 1-30 Entered on FLSD Docket 08/25/2022 Page 4 of 12
`
`pabilities from Release
`depending on value
`alled by the network,
`if signaled)
`intra-frequency RACH
`sistenefit results (i.
`dicated that inter-fred
`has priority &
`frequency RACH
`ment results
`
`Figure 2
`
`

`

`Case 1:22-cv-22706-RNS Document 1-30 Entered on FLSD Docket 08/25/2022 Page 5 of 12
`
`

`

`Case 1:22-cv-22706-RNS Document 1-30 Entered on FLSD Docket 08/25/2022 Page 6 of 12
`
`

`

`US 8,792,432 B2
`
`1.
`PRIORITIZING RACH MESSAGE CONTENTS
`
`TECHNICAL FIELD
`
`The exemplary and non-limiting embodiments of this
`invention relate generally to wireless communication sys
`tems, methods, devices and computer programs, and more
`specifically relate to efficient utilization of uplink RACH
`messages and signaling for implementing Such efficiency.
`
`10
`
`BACKGROUND
`
`2
`the UE is in a RRC-Connected state for routine mobility, base
`station A would like to have those measurements as soon as
`the UE attempts access on the RACH so base station A can
`re-direct the UE's RRC connection to another neighbor base
`station if that neighbor is more appropriate for the requesting
`UE.
`UEs which support features from 3GPP Release 7 and
`onwards Support neighbor cell measurements for both inter
`frequency and intra-frequency neighbors of the RACH base
`station. For such a UE the network/base station A would
`require the UE to send measured results on the RACH for both
`those types of neighbors, but this would exceed the RACH
`message size limit
`To resolve this issue, current 3GPP specifications require
`the UE to check the message size, and if exceeded the UE
`shall omit RACH measured results starting with inter-fre
`quency results. Specifically, subclause 8.5.23 of 3GPP TS
`25.331 V10.0.0 states (emphasis added):
`1> for messages transmitted on CCCH, take care that the
`maximum allowed message size is not exceeded when
`forming the IE “Measured results on RACH', i.e. limit
`the number of included neighbour cells or if required
`omit the IE “Measured results on RACH' altogether.
`When limiting the number of included neighbouring
`cells, the number of inter-frequency cells should be lim
`ited first i.e. inter-frequency cells should be omitted
`before limiting the number of intra-frequency cells.
`In relevant teachings, document R2-104524 which is a
`Change Request for TR25.331 V10.0.0 entitled “ADDITION OF
`OPTIMISED RACH MESSAGE TYPES (3GPP TSG-RAN WG2
`Meeting #71; Madrid, Spain; 23-27 Aug. 2010; by Nokia
`Corporation and Nokia Siemens Networks) introduce a new
`RACH message type which removes the non-critical exten
`sion indicators in abstract syntax notation asn1. But the mes
`sage space saved with this new RACH message type is not
`enough to allow the UE to include neighbor cell measure
`ments for both inter-frequency and intra-frequency neighbors
`in its UL RACH message.
`The inventors consider the current approach in 3GPP as
`static approach and overly limiting, whereas the new RACH
`message noted above is not a solution either. The exemplary
`embodiments presented below resolve the above problems to
`a much greater extent than either the current 3GPP solution or
`the new RACH message type.
`
`SUMMARY
`
`In a first exemplary embodiment of the invention there is an
`apparatus comprising at least one processor and at least one
`memory storing a computer program. In this embodiment the
`at least one memory with the computer program is configured
`with the at least one processor to cause the apparatus to at
`least broadcast an indication for directing a user equipment
`how to prioritize information for inclusion in an uplink mes
`sage to be sent on a random access channel.
`In a second exemplary embodiment of the invention there
`is a method comprising: in a first instance, broadcasting an
`indication having a first value which directs a user equipment
`to prioritize inter-frequency neighbor cell measurements over
`intra-frequency neighbor cell measurements for inclusion in
`an uplink message to be sent on a random access channel; and
`in a second instance, directing a user equipment to prioritize
`intra-frequency neighbor cell measurements over inter-fre
`quency neighbor cell measurements for inclusion in an uplink
`message to be sent on the random access channel by broad
`casting a second value of the indication or by not broadcasting
`the indication.
`
`The following abbreviations that may be found in the
`specification and/or the drawing figures are defined as fol
`lows:
`3GPP third generation partnership project
`BCCH broadcast channel
`CCCH common control channel
`DL downlink (node B towards UE)
`IE information element
`MAC medium access control
`Node B base station
`RACH random access channel
`RRC radio resource control
`UE user equipment
`UL uplink (UE towards node B)
`UTRA universal terrestrial radio access
`UTRAN universal terrestrial radio access network
`UMTS universal mobile telecommunications system
`WCDMA wideband code division multiple access
`Various radio technologies utilize various RACH proce
`dures for a UE to gain contention-based access to a network.
`The RACH is one of multiple CCCHs, and in the UTRAN
`system the RACH procedure includes the UE sending an
`access message which includes a preamble part and a mes
`35
`sage part. The UE seeking connection to a WCDMA base
`station first transmits a preamble (signature sequence) on a
`RACH and then listens on an acquisition indicator channel
`AICH for a acquisition indicator AI corresponding to that
`preamble. If that AI is not received, the UE tries again and
`continues the process until it receives a corresponding AI. At
`that point the UE can then transmit the message part of its
`access message, which is also sent UL on the RACH. This
`message part is termed a RRC Connection Request in
`UTRAN.
`Being on the RACH, the transport block size of the UE's
`RRC Connection Request message is tightly limited. Several
`3GPP releases have added extensions to this message and it is
`now near if not at its size limit. Specifically, the maximum
`size of UL CCCH messages is 166 bits: the RACH transport
`block size (168 bits) less the size of the MAC header (2 bits).
`A more detailed analysis of this bit-size may be seen at
`document R2-105713 entitled 'ANALYSIS ON RACH SIGNAL
`LING” (3GPP TSG-RAN WG2 Meeting #71bis: Xian, China:
`11-15 Oct. 2010; by Nokia Corporation and Nokia Siemens
`Networks), which sets forth that there are currently occasions
`in which the 166 bit size is too limiting.
`One type of information which the UE reports on the
`RACH in its RRC Connection Request message is neighbor
`cell measurements. Consider FIG. 1: the UE sends its RRC
`60
`Connection Message UL to base station A on that station’s
`RACH, but this UE is near the border of two other cells
`controlled by respective base stations B and C. Base station A
`would like to have the UE's neighbor cell measurements from
`those other cells So it can make timely and proper decisions
`for handing over the UE. While the UE also sends neighbor
`cell measurements at other times and on other channels once
`
`15
`
`25
`
`30
`
`40
`
`45
`
`50
`
`55
`
`65
`
`Case 1:22-cv-22706-RNS Document 1-30 Entered on FLSD Docket 08/25/2022 Page 7 of 12
`
`

`

`US 8,792,432 B2
`
`3
`In a third exemplary embodiment of the invention there is
`a computer readable memory storing a computer program
`comprising code for broadcasting an indication to direct a
`user equipment how to prioritize information for inclusion in
`an uplink message to be sent on a random access channel.
`In a fourth exemplary embodiment of the invention there is
`an apparatus comprising at least one processor and at least
`one memory storing a computer program. In this embodiment
`the at least one memory with the computer program is con
`figured with the at least one processor to cause the apparatus
`to at least: receive abroadcast indication for prioritizing infor
`mation for inclusion in an uplink message to be sent on a
`random access channel; and construct the uplink message
`which includes information that is prioritized in accordance
`with the broadcast indication so as not to exceed a maximum
`message size.
`In a fifth exemplary embodiment of the invention there is a
`method comprising: receiving a broadcast indication for pri
`oritizing information for inclusion in an uplink message to be
`sent on a random access channel; and constructing the uplink
`message which includes information that is prioritized in
`accordance with the broadcast indication so as not to exceed
`a maximum message size.
`In a sixth exemplary embodiment of the invention there is
`a computer readable memory storing a computer program
`comprising: code for receiving a broadcast indication for
`prioritizing information for inclusion in an uplink message to
`be sent on a random access channel; and code for constructing
`the uplink message which includes information that is priori
`tized in accordance with the broadcast indication so as not to
`exceed a maximum message size.
`These and other embodiments and aspects are detailed
`below with particularity.
`
`10
`
`15
`
`25
`
`30
`
`4
`Generally, a base station/cell is considered intra-frequency
`with respect to base station/cell A when it uses a same radio
`frequency for UE connections as does base station/cell A, and
`is inter-frequency with respect to base station/cell A when it
`uses a different radio frequency for UE connections as does
`base station/cell A.
`Some networks use the inter-frequency measurement
`results to determine whether the RRC connection can be
`redirected to another frequency (for example, for load bal
`ancing, or for a particular service). If the UE omits these
`results as is always the case under current 3GPP specifica
`tions whenever the CCH message size is limiting to what the
`UE can report, then the network can no longer use this infor
`mation to determine whether re-direction is possible. This
`will impact certain network load-balancing algorithms and
`potentially impact the reliability of re-direction. But the more
`common case in practice is for the base station to use the
`inter-frequency measurement results for re-directing the UE
`to another frequency. Using intra-frequency measurement
`results for a soft handoverina UEconnection setup is not very
`common in practice.
`Exemplary embodiments of this invention give the network
`(e.g., base station A) the option of having the UE report the
`inter-frequency measurement results and omit the intra-fre
`quency measurement results where the CCCH message size
`will not admit them both. In an exemplary embodiment the
`network exercises this option by indicting in signaling how to
`perform prioritization of RACH measurement results which
`are to be included or omitted if the transport block size is
`insufficient to include all measurement results.
`In one exemplary embodiment, the network utilizes inter
`frequency measurement results and so the network indicates
`that inter-frequency measurement results have priority over
`intra-frequency measurement results. In this embodiment the
`network makes this indication in the system information
`which it broadcasts. For this case, the UE in response to
`reading that indication in the system information shall first
`omit intra-frequency measurement results in order that the
`message size is not exceeded. By example, this indication can
`be implemented as only a single bit in system information. If
`the bit has one value the UE shall first omit intra-frequency
`measurement results, and if the bit has an opposite value or is
`not broadcast at all then the UE shall first omit inter-fre
`quency measurement results as is the current but inflexible
`practice in 3GPP specifications.
`The above embodiment may be implemented by adoption
`into a wireless specification. By example, Such a specification
`might incorporate the following exemplary but non-limiting
`language which is adapted from that in the background sec
`tion to reflect this aspect of the invention:
`1> for messages transmitted on CCCH, take care that the
`maximum allowed message size is not exceeded when
`forming the IE “Measured results on RACH', i.e. limit
`the number of included neighbour cells or if required
`omit the IE “Measured results on RACH' altogether.
`When limiting the number of included neighbouring
`cells:
`2> If the IE “prioritise inter-frequency RACK measure
`ment results' is present and set to “TRUE'
`3> the number of intra frequency cells should be
`limited first i.e. intra frequency cells should be
`omitted before limiting the number of inter-fre
`quency cells.
`2> Otherwise:
`3> the number of inter-frequency cells should be lim
`ited first i.e. inter-frequency cells should be omitted
`before limiting the number of intra-frequency cells.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`35
`
`FIG. 1 is a schematic drawing of neighboring wireless
`network cells with a user equipment within one cell for illus
`trating an exemplary environment in which embodiments of
`the invention may be practiced to advantage.
`40
`FIG. 2 is a process flow diagram illustrating discrete steps
`and decisions according to an exemplary embodiment of the
`invention.
`FIGS. 3A-B are logic flow diagrams illustrating from the
`respective perspectives of a network access node and a user
`equipment the operation of a method, and a result of execu
`tion of computer program instructions embodied on a com
`puter readable memory, in accordance with the exemplary
`embodiments of this invention.
`FIG. 4 is a simplified block diagram of a UE in communi
`cation with a wireless network including a radio network
`controller RNC and a Node B, and illustrates exemplary
`electronic devices Suitable for use in practicing exemplary
`embodiments of this invention.
`
`50
`
`45
`
`DETAILED DESCRIPTION
`
`55
`
`Assume for example that base station B of FIG. 1 is an
`inter-frequency neighbor of base station A, and base station C
`is an intra-frequency neighbor of base station A. The UE takes
`60
`measurements of both but there is insufficient headroom in
`the RRC Connection Request message to include both mea
`Surement results. If the UE followed the current 3GPP direc
`tive noted in the background section above it would always
`send only the measurement results for base station C which is
`an intra-frequency neighbor cell and omit the inter-frequency
`neighbor cell measurement results for base station B.
`
`65
`
`Case 1:22-cv-22706-RNS Document 1-30 Entered on FLSD Docket 08/25/2022 Page 8 of 12
`
`

`

`US 8,792,432 B2
`
`10
`
`15
`
`35
`
`40
`
`45
`
`5
`In another embodiment, the above flexible priority is used
`in conjunction with the new RACH message type detailed at
`document R2-104524 (referenced in the background section
`above). This makes it less likely that the measurement results
`will exceed the upwardly-limited size of the RACH message.
`But if some measurement results still must be omitted, then
`by omitting the intra-frequency results in accordance with the
`indicator in the system information still allows the network to
`perform re-redirection based on the inter-frequency measure
`ments which the UE does include in its UL RACH message.
`If the above measurement result prioritization indication is
`considered a first indication, then the network may also
`broadcast a second indication to indicate whether or not it
`supports the new RACH message type. By example, the first
`and second indications can be implemented as two bits in
`system information: one bit as the first indication to indicate
`how to prioritize the inter-frequency/intra-frequency mea
`Surement results, and another bit as the second indication to
`indicate whether the network supports the new RACH mes
`sage format.
`In a further exemplary embodiment which may be utilized
`with or without the new RACH message type, the network
`sends a third indication which indicates whether to prioritize
`particular RACH measurement results over particular UE
`capabilities for inclusion in the UL RACH message. Since
`25
`this third indication may be used in various embodiments
`with or without the above-detailed second indication, this
`third indication is alternatively referred to herein as a further
`indication. For example, the network may use this third or
`further indication to indicate that the network supports fea
`30
`tures only from Release 8 and earlier. The UE which is com
`patible with Release 9 or Release 10 does not need to indicate
`in its RACH message whether it can support features which
`are specific to Release 9 or 10, since the network cannot
`utilize those features anyway. From this third or further indi
`cation the UE knows to prioritize measurement results over
`Release 9/10 features for inclusion in the UL RACH message.
`Additional bits beyond the first indication (and second indi
`cation of there are different RACH message types in use) are
`added to system information for this third or further indica
`tion; for example an enumerated type could be used to indi
`cate which release the network Supports, and hence from what
`release the UE can omit capabilities from its RACH message.
`FIG. 2 illustrates an overview of the above process. At
`block 202 the network broadcasts on its BCCH prioritization
`information (indication) for prioritizing measurement results
`for inclusion in ULCCCH/RACH messages. At block 204 the
`UE, after having listened to the BCCH, triggers connection
`establishment and constructs a RRC Connection Request
`message. At block 206 the UE checks the size of that message,
`which is not yet sent, against the maximum transport block
`size allowed on the CCCH/RACH. If the message size
`checked at block 206 does not exceed the maximum, then
`block 208 applies and the UE transmits the RRC Connection
`Request message which it constructed at block 204. If the
`message size checked at block 206 does exceed the maxi
`mum, then block 210 applies and the UE omits information
`elements IEs in the order of prioritization signaled by the
`network at block 202.
`By example, block 210 operates as follows. If the network
`60
`sent a third or further indication as detailed above the UE
`selectively drops from the block 204-constructed message
`any of its own capabilities included in that message which are
`beyond the network's own capabilities as indicated in that
`third/further indication. The UE re-checks the message size at
`block 206, and if it still exceeds the maximum then block 210
`is re-entered. From the first indication as detailed above
`
`50
`
`Case 1:22-cv-22706-RNS Document 1-30 Entered on FLSD Docket 08/25/2022 Page 9 of 12
`
`55
`
`65
`
`6
`which was broadcast at block 202, the UE selectively drops
`from what remains of the block 204-constructed message the
`intra-frequency measurement results or the inter-frequency
`measurement results, whichever is indicated by that first indi
`cation as having the lesser priority.
`FIGS. 3A-B are logic flow diagrams which describe these
`exemplary embodiments of the invention from the perspec
`tive of the access node/base station and the UE, respectively.
`FIGS. 3A-B may each be considered to illustrate the opera
`tion of a method, and a result of execution of a program of
`computer instructions stored in a computer readable memory,
`and a specific manner in which components of an electronic
`device are configured to cause that electronic device to oper
`ate. The various blocks shown in FIGS. 3A-B may also be
`considered as a plurality of coupled logic circuit elements
`constructed to carry out the associated function(s), or specific
`result of strings of computer program code stored in a
`memory.
`From the perspective of the base station, in FIG. 3A there
`is broadcast at block 302 an indication to direct a user equip
`ment how to prioritize information for inclusion in an uplink
`message to be sent on a random access channel. Further
`elements of FIG. 3A are optional and go to the specific exem
`plary embodiments variously detailed above.
`Block 304 specifies that a first value of the indication
`directs a UE to prioritize inter-frequency neighbor cell mea
`Surements over intra-frequency neighbor cell measurements
`for inclusion in the uplink message; and a second value of the
`indication or outright omission of the indication from being
`broadcast directs a UE to prioritize intra-frequency neighbor
`cell measurements over inter-frequency neighbor cell mea
`surements for inclusion in the uplink message. Blocks 302
`and 304 may be combined from the base station’s perspective
`to broadcast in a first instance the indication having the first
`value and in a second instance broadcasting the indication
`having the second value or not broadcasting the indication at
`all, since the network/base station can change the value of that
`indication (or refrain from broadcasting it) as the network
`deems appropriate.
`At block 306, if we consider the indication at block 302/
`304 as a first indication then the base station broadcasts a
`second indication in the system information for indicating
`that the base station Supports different message types.
`And at block 308, which may be combined with block 306
`but not necessarily, the base station broadcasts a third or
`further indication in the system information for prioritizing
`neighbor cell measurement results over capabilities of the
`user equipment for inclusion in the uplink message to be sent
`on the random access channel.
`From the perspective of the UE, in FIG. 3B there is
`received at block 310 a broadcast indication for prioritizing
`information for inclusion in an uplink message to be sent on
`a random access channel. At block 312 the UE constructs the
`uplink message which includes information that is prioritized
`in accordance with the broadcast indication so as not to
`exceed a maximum message size. Further elements of FIG.
`3B are optional and go to the specific exemplary embodi
`ments variously detailed above.
`Block 314 specifies that a first value of the indication
`directs that inter-frequency neighbor cell measurements are
`prioritized over intra-frequency neighbor cell measurements
`for inclusion in the uplink message; and a second value of the
`indication or omission of the indication altogether directs that
`intra-frequency neighbor cell measurements are prioritized
`over inter-frequency neighbor cell measurements for inclu
`sion in the uplink message.
`
`

`

`US 8,792,432 B2
`
`10
`
`15
`
`25
`
`30
`
`35
`
`40
`
`50
`
`7
`If we consider the indication received at block 310 as a first
`indication then the UE receives at block 316 a broadcast
`second indication in the system information for indicating
`that the access node Supports different message types, in
`which different ones of the message types allow different
`volumes of the prioritized information.
`And at block 318, which may be combined with block 316
`but not necessarily, the UE receives a broadcast third or fur
`ther indication in the system information for prioritizing
`neighbor cell measurement results over capabilities of the UE
`for inclusion in the uplink message to be sent on the RACH.
`In this case the constructing of block 312 means that the UE
`constructs the uplink message to include information that is
`prioritized in accordance with the broadcast first and third/
`further indications so as not to exceed the maximum message
`S17C.
`The blocks of FIGS. 3A-B and the functions they represent
`are non-limiting examples, and may be practiced in various
`components such as integrated circuit chips and modules, and
`that the exemplary embodiments of this invention may be
`realized in an apparatus that is embodied as an integrated
`circuit. The integrated circuit, or circuits, may comprise cir
`cuitry (as well as possibly firmware) for embodying at least
`one or more of a data processor or data processors, a digital
`signal processor or processors, baseband circuitry and radio
`frequency circuitry that are configurable so as to operate in
`accordance with the exemplary embodiments of this inven
`tion.
`One technical effect and advantage of these exemplary
`embodiments is that the UE is enabled to prioritize the content
`of the RRC Connection Request message more efficiently, an
`effect which is enhanced even further by the second and/or
`third indications detailed above. The solutions presented
`herein also avoids features in the network being redundant, or
`unusable or unreliable, and also provides a general frame
`work for extending the RRCConnection Request to remain a
`viable message for future releases of UTRAN and E-UT
`RAN.
`Reference is now made to FIG. 4 for illustrating a simpli
`fied block diagram of various electronic devices and appara
`tus that are suitable for use in practicing the exemplary
`embodiments of this invention. In FIG. 4 a wireless network
`(node B 22 and RNC 24) is adapted for communication over
`a wireless link 21 with an apparatus, such as a mobile terminal
`or UE 20, via a network access node, Such as a base or relay
`45
`station or more specifically a node B 22. The network may
`include a node (e.g., the RNC 24) which provides connectiv
`ity with further networks (e.g., a publicly switched telephone
`network PSTN and/or a data communications network/Inter
`net).
`The UE20 includes processing means such as at least one
`data processor (DP) 20A, storing means such as at least one
`computer-readable memory (MEM) 20B storing at least one
`computer program (PROG) 20O, communicating means Such
`as a transmitter TX 2.0D and a receiver RX 20E for bidirec
`tional wireless communications with the node B 22 via one or
`more antennas 20F. Also stored in the MEM20B is an algo
`rithm or a set of rules 20O for prioritizing RRC Connection
`Request messages according to values of indicators received
`on broadcast channels.
`The node B 22 also includes processing means such as at
`least one data processor (DP) 22A, storing means such as at
`least one computer-readable memory (MEM) 22B storing at
`least one computer program (PROG) 22C, and communicat
`ing means such as a transmitter TX22D and a receiver RX
`65
`22E for bidirectional wireless communications with the UE
`20 via one or more antennas 22F. There is a data and/or
`
`55
`
`Case 1:22-cv-22706-RNS Document 1-30 Entered on FLSD Docket 08/25/2022 Page 10 of 12
`
`60
`
`8
`control path 25 coupling the node B 22 with the RNC 24, and
`another data and/or control path 23 coupling the node B 22 to
`other node B's/access nodes. Also stored in the MEM22B of
`the node B 22 is an algorithm or a set of rules 22G for
`prioritizing RRCConnection Request messages according to
`values of indicators received on broadcast channels, so the
`node B 22 knows what values to set for the indicators it
`broadcasts.
`The RNC 24 includes processing means such as at least one
`data processor (DP) 24A, storing means Such as at least one
`computer-readable memory (MEM) 24B storing at least one
`computer program (PROG) 24C, and communicating means
`Such as a modem 24H forbidirectional wireless communica
`tions with the Node B 22 via the data/control path 25. While
`not particularly illustrated for the UE20 or node B 22, those
`devices are also assumed to include as part of their wireless
`communicating means a modem which may be inbuilt on an
`RF front end chip within those devices 20, 22 and which also
`carries the TX 2.0D/22D and the RX 20E/22E.
`At least one of the PROGS 20O in the UE20 is assumed to
`include program instructions that, when executed by the asso
`ciated DP 20A, enable the device to operate in accordance
`with the exemplary embodiments of this invention, as
`detailed above. The UE20 and the node B 22 may also have
`Software to implement certain aspects of these teachings for
`implementing the indications/indicators which are broadcast
`DL. In these regards the exemplary embodiments of this
`invention may be implemented at least in part by computer
`software stored on the MEM20B, 22B which is executable by
`the DP 20A of the UE20 and/or by the DP 22A of the node B
`22, or by hardware, or by a combination of tangibly stored
`software and hardware (and tangibly stored firmware). Elec
`tronic devices implementing these aspects of the invention
`need not be the entire UE 20 or node B 22, but exemplary
`embodiments may be implemented by one or more compo
`nents of same such as the above described tangibly stored
`software, hardware, firmware and DP or a system on a chip
`SOC or an application specific integrated

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket